[Week 4] Google IT Support Professional Certificate #27 | Course 4 System Administration and IT Infrastructure Services {Part 3}

in #education6 years ago (edited)

Add heading (6).jpg

This is part 3 for part 2 click here--------------- http://bit.ly/2BYdNDI

13. Group Policy Inheritance and Precedence


If you follow the practice of creating specific GPOs to address specific categories of needs, you can end up with a whole lot of policies linked at many levels of your Active Directory hierarchy. Group Policy Objects that control security settings are a really common place where this can happen. Systems administrators are responsible for protecting the security of the IT infrastructure. So, it's a good practice to create a very restrictive GPO that uses very secure conservative security policies and link that to the whole domain. This gives you a secure default policy but some users or computers may not be able to do what they need to with those very conservative policies in place. The finance department might need to use Excel macros that are disabled in your default security policy for example. So, we can create GPOs that relax some of the security settings or policies in the OUs that contain those computers or users. Another example might be that we have a Group Policy Object that standardize the desktop wallpaper of all computers. But we have computers that are public access kiosks that need to have a different wallpaper. In any of these cases, you can have computers or user accounts with multiple GPOs assigned to them that contradict one another by design. So, what happens when there are two or more contradictory Group Policy Objects that apply to the same compute? When computers processing the Group Policy Objects that apply to it, all of these policies will be applied in a specific order based on a set of precedents rules. GPOs are applied based on the containers that contain the computer and user account. GPOs that are linked to the least specific or largest container are applied first. GPOs that are linked to the most specific or smallest container are applied last. First, any GPOs linked at the AD site are applied then any link at the domain. And then any OUs in order from parent to child. If more than one policy tries to set the same policy or preferences, then the most specific policy wins. To see what I mean, let's look at this AD structure. As you can see my structure, I have multiple OUs. We have my IT OU, we have my sales OU, I also have my research OU. And I also have my sites in Australia, India, and North America. If you have a computer in the India site and the example.com sales computer OU then Active Directory would apply Group Policy Objects that are linked to the India site, the example.com domain, the sales OU, and the computers OU in that order.
ad.jpg
That's not all though. You can actually link multiple GPOs to the same container. How does AD decide which order to apply the GPOs in if there are more than one in a container? Each container has a link order for the GPOs that are linked to it. So, let's look at our sales OU. The sales OU in our example domain has a GPO for a network drive mapping and a GPO for configuring network printers. The link order of each policy determines which GPO takes precedence.
link order.jpg
The highest number is the lowest ranked GPO, so its settings are applied first. Network printers, sales is applied first and network drives, sales is applied last. If anything the network drive policy contradicts the network printer policy and the drives policy wins out. Let's summarize this so far. The highest numbered link order in the least specific container is applied first. And the lowest numbered link order in the most specific container is the last GPO applied. The last GPO to modify any specific setting wins. And the group policy management console, we can see the precedence rules in action. I'm going to switch to the computers OU in group policy management. I can see that there is a policy linked here called Computer Security Policy, I want to increase this. By switching from the link Group Policy Objects tab to the Group Policy Inheritance, like so, I can see that objects in this OU will actually have quite a few policies applied. The precedence column tells us which policy will win if there are conflicting settings, and the location column tells us where the policy was linked.
precedence.jpg
You might have noticed that there are no site link policy listed here. That's because you can have computers from many different AD sites in the same OU. So, site based GPO links aren't represented in this summary. When you add all of the group policies together for a specific machine and apply precedence rules to them, we call that the Resultant Set of Policy or RSoP for that machine. When you're troubleshooting group policy, you often compare an RSoP report, pronounced "Haar sope" to what you expect to be applied to that computer. There are a lot of ways to get RSoP report. We will use the group policy management console for now and look at the other method when we start troubleshooting. Let's check on what Group Policy Objects will apply when one of our sales staff logs onto their computers or right click on the group policy results node in GPMC and select group policy result wizards. Let me go and do that. This wizard will walk me through generating a Resultant Set of Policy report for the computer and user my choice. The computer that I'm using to run this report will make a remote connection to that computer and ask it to run the report. The report would then be visible in my local GPMC. I'd like to see that RSoP when Emmett is logged into his computer which is EMMETPC01. Let me go and do that, so I'm going to hit next. I want to search for his computer. So, I hit another computer, hit browse and type in EMMETPC01 and hit okay. The group policy results in wizard it's super simple. First, I enter EMMETPC01 as a computer that I want to run the report on. By default, the wizard will only run an RSoP report for computer configuration. Since I want to see the user configuration for EMMET2, I will select display policy setting for him which is actually always selected by default. So, what we going to do is we going to hit next and it's going to take us to the summary of selections.
gpo wizard.jpg
And then we going to hit next and to generate the report, we hit Finish. I will hit close. You can only select users from this list who've already logged onto this computer in the past. That's it. I review my selection in the summary dialog then finish the wizard. I'm left with a new item under the Group Policy resultant node in GPMC and it contains a Resultant Set of Policy report that I just requested. Great. This RSoP report contains everything that we need to understand what policies apply to a computer or user. It includes a whole lot of detail about where the computer and user are located in AD, what their security group memberships are and more. I'm going to set that aside for the moment and focus on the setting sections of the report. Which I am going to scroll down to. This looks a lot like the information you see in the settings tab of a GPO but instead of only showing you the settings modified by a single GPO, you can see the combined effect of all of the applied GPOs.
rsop.jpg
The winning GPO column tells you which GPO ultimately took precedence for each policy and preference. Amazing, right? Remember, I am making a remote request for my group policy management console to EMMETPC01 to run this report. There are a bunch of reasons that this could fail to work. EMMETPC01 may be powered off, it could be disconnected from the network or have firewalls that prevent me from running the report remotely. If I'm not a local administrator on the machine, I won't be able to run the report. In any of these cases, if I need that RSoP report for troubleshooting, I might have to run commands locally on Emmett's PC01. Will cover additional troubleshooting techniques in a future lesson.

14. Group Policy Troubleshooting


As a systems administrator, or IT support specialist, you might be called on to troubleshoot issues related to Active Directory. Let's go through some of the most common troubleshooting tasks that you may encounter. This lesson will introduce you to tools that will help you troubleshoot these scenarios. Keep in mind, these are only examples. Since we're working with complex systems, there are lots and lots of ways for things to not work. Your greatest tool is to learn about these systems and understand how they function. Thoughtful troubleshooting and research are your friends. One of the most common issues you might encounter is when a user isn't able to log into their computer or isn't able to authenticate to the Active Directory domain. There are many reasons this might happen. They may have typed the password with caps lock button on. They may have locked themselves out of their computer, actually changed a system setting, or it could be a software bug. It's important to think about the steps to troubleshoot and remember to ask questions about what happened. Make sure to look at the exact conditions under which the failure occurs and any error message that accompany the failure. This should be enough information to get you started down the right path to troubleshoot. Let's just talk for a moment about the most common types of failures that can lead to a user account authentication issue. As we discussed in the earlier lesson, if a user enters a wrong password several times in a row, their account may be locked out. People sometimes just forget their passwords and need a systems administrator to sort things out. Make sure to review our earlier lesson on managing user and groups in Active Directory if you need a refresher on resetting user passwords. If a domain computer isn't able to locate a domain controller that it can use for authentication, then nothing that relies on Active Directory authentication will work. If you remember, from the customer support module in the first course, any time you troubleshoot an issue, start with the simplest solution first. This could be a network connectivity issue and nothing specific to Active Directory at all. If the computer isn't attached to a network that can route communications to the domain controller, then this must be fixed. You also learned about network troubleshooting techniques in an earlier module, so we won't repeat any of them here. Any networking issue that would prevent the computer from contacting the domain controller or its configured DNS servers, which is used to find domain controller, could be an issue. Now, why is DNS so important? In order for the computer to contact a domain controller, it needs to find one first. This is done using DNS records. The domain computer will make a DNS request for the SRV records matching the domain that it's been bound to. If a computer can't contact its DNS servers, or if those DNS servers don't have the SRV records that the computer is looking for, then it won't be able to find the domain controller. The SRV records that we're interested in are _ldap._tcp.dc._msdcs.DOMAIN.NAME, where domain name is the DNS name of our domain. So I'm going to go ahead to my PowerShell, and I want to go ahead and type in Resolve-DNSName -Type SRV -Name _ldap._tcp.dc._msdcs.example.com. That looks good. I should see an SRV record for each of my domain controllers. And I do. Perfect. Now, if I can't resolve the SRV records for my domain controllers, then my DNS servers may be misconfigured.
srv record.jpg
How might they be misconfigured? Well, my domain computers need to use the DNS servers that host my active directory domain records. This will often be one or more of my domain controllers, but it can be a different domain server. Either way, the appropriate DNS servers to use for your domain computers should be known and documented. Compare the configuration of the machine to the known good configuration and see if it needs to be adjusted. On the flip side, if you're resolving some SRV records, but they appear to be incomplete or incorrect, then in-depth troubleshooting may be required. I've included a link to more information about this in the next reading. One more thing to call out. Depending on the configuration of your domain and your computers, it's common that local authentication will continue to work, for a little while least. Once someone logs into a domain computer, information required to authenticate that user is copied to the local machine. This means that after the first login, you'll be able to log in to the computer, even if the network is disconnected. You won't be authenticated to the domain or authorized access to any domain resources like shared folders. Just because someone is able to log in doesn't mean that they're able to find a domain controller. Another issue that can prevent users from authenticating has to do with the clock. Kerberos is the authentication protocol that AD uses, and it's sensitive to time differences. I'm not talking about local time zones here. I mean the relative UTC time. If the domain controller and computer don't agree on the UTC time, usually within five minutes, then the authentication attempt will fail. Domain computers usually synchronize their time with domain controllers with the Windows Time service, but this can sometimes fail. If the computer is disconnected from a domain network for too long, or if the time is changed by software or a local administrator to be too far out of sync, then the computer may not automatically re-sync with a domain controller. You can manually force a domain computer to re-sync by using the w32tm/rsync command. I've included links with more information about this in the next reading. Now, let's talk a bit about troubleshooting group policy issues. A common issue that you might have to troubleshoot is when a GPO-defined policy or a preference fails to apply to a computer. You might learn about this failure in a number of ways, like a person in your organization telling you that something on their computer is missing or not working. If you're using GPO to manage configuration on your machines, then maybe there will be a piece of software that should be present, or there may be a mapped network drive that's missing or a number of things. The common factor will be that something that you created a GPO to configure won't be configured on one or more computers. Let's look at the three most common reasons that this might happen. The first, and possibly most common type of GPO failure, has to do with the way group policies are applied. Depending on how your domain is configured, the group policy engine that applies policy settings to a local machine may sacrifice the immediate application of some types of policies in order to make logon faster. This is called Fast Logon Optimization, and it can mean that some GPO changes take much longer to be automatically applied than you might expect. Also, the group policy engine usually tries to make GPO application faster by only applying changes to a GPO instead of the whole GPO. In either of these examples, you can force all GPOs to be applied completely and immediately with gpupdate/force. If you want to be really thorough, you can run gpupdate/force/sync. Adding the /sync parameter will make you log off and reboot the computer. Some types of group policy can only run when the computer is first booted or when a user first logs on. So a log off and reboot is the only way to make sure that a forced updated GPO has a chance to apply all of the settings. Replication failure is another reason that a GPO might fail to apply as expected. Remember that when changes are made to Active Directory, those changes usually take place on a single domain controller. Those changes then have to be replicated out to other domain controllers. If replication fails, then different computers on your network can have different ideas about the state of directory objects, like group policy objects. The logon server environment variable will contain the name of the domain controller that the computer used to log on. Remember that you can see the contents of the variable with this command in PowerShell, which is $env:LOGONSERVER. It shows me DC 1.
logon server.jpg
You could also get the same results using command prompt which uses %LOGONSERVER%. Knowing which domain control you're connected to is useful information to have if you suspect a replication issue. From the group policy management console, we can check on the overall health of the group policy infrastructure. I'm going to select my domain and take a look at the status tab. This tab will summarize the Active Directory and assist all replication status for the domain. It may be showing result from a recent test so I'm going to force it to run a new analysis by clicking on Detect Now. What we want to see is that all of our domain controllers are listed under domain controllers with replication in sync.
report.jpg
If they are, then we can be sure that there are no replication issues that will affect our group policy objects. If we do see any domain controllers in the domain controller with replication in progress list, then we may have a replication issue. Depending on the size and complexity of your Active Directory infrastructure and the reliability and throughput of the network links between your AD sites, it's possible for a replication to take a few minutes to complete. If replication doesn't complete in a reasonable amount of time, you may need to troubleshoot Active Directory replication. In the supplemental reading, you'll find a handy guide to help you through this more advanced topic. We've focused on the simplest cases for managing group policy. But the reality is that controlling the scope of a group policy object can get super complicated. Take a look at the supplemental reading to learn more about this topic, too. If you're trying to work out why a particular GPO isn't applying to a computer, the first thing to do is to run the resultant set of policy, or RSOP. You can use the group policy management console, like we did in an earlier lesson, or you can run a command on a computer directly to generate the report. The GP result command will help us out there. If I run gpresult /R, you can see that I get a summary report in my terminal. Let me go and show you that. So I'm switching to my PowerShell, gpresult /R. Report being created, and I get this report.
gpresult.jpg
If I want the full report, like I get from my GP MC, I can run gpresult /H FILENAME.html.
gp result.jpg
I'm going to do gpresult /H and then test.html. This will give me a report that's an HTML web page that I can open in my browser, so let me go and get that.
html.jpg
Okay, so with this report in hand, I want to look for some things. Is the GPO that I want to apply listed? Was it linked to an OU that contains a computer that I'm troubleshooting? Is the GPO that I care about listed under applied GPOs or under denied GPOs? If it was denied, what was denied reason? Did another GPO win for the policy or preference that I'm trying to configure? Each GPO can be configured with an actual called a security filter. Is the security filter set to something besides authenticated users? If so, then that may mean that you have to be in a specific group in order to read or apply the GPO. Each GPO can also be configured with the WMI filter. A WMI filter lets you apply GPO based on the configuration of the computer. WMI filters are powerful, but expensive, and easy to misconfigure. This is because they look at Windows management instrumentation values to decide if a policy should apply or not. For example, if you could create a GPO that installs a piece of software, but only if a WMI reports that a specific piece of hardware is present. These filters are expensive because they require the group policy engine to perform some sort of query or calculation on every computer that's linked to the policy, but then only apply the GPO to computers that match the filter. Many policies and preferences can be configured to apply to the computer or to users as they log on. Did you mean to configure a computer setting but accidentally configure a user setting, or the reverse? There's a really in-depth group policy troubleshooting guide in the supplemental reading that you should refer to if you get into a really tricky GPO troubleshooting session. We've really covered a lot out here. If you aren't clear on any of the concepts we've covered, that's okay. Just make sure to re-watch the lessons. Remember though, that the more you work with Active Directory and the group policy, the more familiar you become with them. If you use what you've learned about these systems combined with your research skills, you can troubleshoot just about anything.

More information on how you can manually force a domain computer to resync by using the w32tm /resync command found here https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/windows-time-service/how-the-windows-time-service-works and here. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb491016(v=technet.10)

More information on how to troubleshoot Active Directory replication can be found here. https://msdn.microsoft.com/en-us/library/bb727055.aspx

More information on controlling the scope of a Group Policy Object can be found here https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772166(v=ws.11) and found here. https://technet.microsoft.com/en-us/library/jj134176(v=ws.11).aspx

More information on the gpresult command can be found here. https://technet.microsoft.com/en-us/library/cc733160(v=ws.11).aspx

More information on how to create a WMI filter can be found here. https://technet.microsoft.com/en-us/library/cc770562(v=ws.11).aspx

15. What is OpenLDAP?


In the last lesson you dove headfirst into the popular directory service Active Directory. You learned how to add users, password, groups and even modify access level for groups, using group policies. Another popular directory service that's used today is the free and open source service OpenLDAP. OpenLDAP, which stands for lightweight directory access protocol operates very similar to Active Directory. Using LDAP notation or LDAP data interchange format, or LDIF, you can authenticate, add, remove users, groups, computers and so on in a directory service. OpenLDAP can be used on any operating system, including Linux, macOS, even Microsoft Windows. However, since Active Directory is Microsoft's propriety software for directory services, we recommend that you use that on Windows instead of OpenLDAP. But its helpful to know that OpenLDAP is open source so it can be used on a variety of platforms. There are a few ways you can interact with an OpenLDAP directory. First, you can use the command-line interface and passing commands to create and manage directory entries. You can also use a tool like phpLDAPadmin, which offers you a web interface that you can use to manage your directory data, much like the Windows Active Directory GUI that you're familiar with. You can read more about how to set up OpenLDAP and phpLDAPadmin in the next reading. In this lesson we'll give you a high level overview of the operations you can do in OpenLDAP via commands and how they work. To begin we'll just open the OpenLDAP package using this command. I'm going to get into my Linux environment and type up this command. Sudo apt-get install slapd ldap-utils.
install ldap.jpg
Put my password in and accept.

Once you install the packages it'll prompt you enter in an administrative password for LDAP. So let's go ahead and do that.

And then hit Ok.

Then confirm your password, then hit Ok.

Now that it's installed we're actually going to reconfigure the slapd package so that we can fine tune our setting. To do that we're going to run the following command.

I'm going to clear my window, and then run sudo dpkg-reconfigure slapd.
reconfigure slapd.jpg

omit.jpg
dns name.jpg
![org name.jpg]
()
password.jpg
mdb.jpg
purged.jpg
old db.jpg
ldapv2.jpg
configure.jpg
This is going to ask us a bunch of questions about our new setup. We won't answer all of these options, but you can learn more about them in, you've guessed it, the supplemental reading. For now let's just fill out the settings with these values. So the first option is Omit OpenLDAP server configuration? I'm going to go ahead and say No. Next, DNS domain name, is similar to Windows AD, this is our organization domain. Let's use example.com.

And then hit Ok.

Organization name, let's use example.

Administrator password, let's do the same thing that we entered before.

For the database let's use MBD. Do you want the database to be removed when slapd is purged? Let's go ahead and say No. Then it's asking us if we would like to move old database. We're going to say Yes for now. And then it'll say, Allow LDAP version 2 protocol? I'm going to say No.

That's it, now you have a running OpenLDAP server. We're really cooking now. Let's keep going.
For more information about installing and configuring OpenLDAP and phpLDAPAdmin on Ubuntu 16.04, click here https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-openldap-and-phpldapadmin-on-ubuntu-16-04
or check out this article on openldap.org. https://www.openldap.org/doc/admin24/slapdconf2.html

16. Managing OpenLDAP


It's easy to manage OpenLDAP through a web browser and tool like phpLDAPadmin, but you can also use command line tools to achieve the same result. I'd recommend you look into setting up PHPLDAPadmin, if this is your first set up with open LDPA. For instructions about how to set up a PHPLDAPadmin, check out the supplementary readings. In this lesson, we're going to quickly run down a few other commands that will allow you to add, modify and remove entries in your directory. To begin using command line tools, you need to use something known as LDIF files, pronounced LDIF. We've already seen LDIF format or LDAP notation in action. It's just a text file that lists attributes and values that describe something. Here's a simple example of an LDIF file for a user. Even without understanding what the syntax of this file is saying, we can infer that it's talking about an employee named Cindy
dn.jpg
who works in the Engineering department at the company example.com. We've talked a little bit what the attributes are referring to in an earlier lesson. But you can refer to the supplemental reading if you want to know what the specific fields mean. For our purposes here, though, we just want to see a high level overview of how this works. Once you've written your LDIF files, you're practically done. Depending on what task you want to do to your directory, you'd run commands like these. Ldapadd, this takes the input of an LDIF file, and adds the context of the files. ldapmodify, as you can guess, this modifies an existing object. ldapdelete, this will remove the object that the LDIF file refers to. ldapsearch, this will search for entries in your directory database.

It's not important to note the syntax of these commands, you can always look up a syntax on official documentation. But as you can see, it's not scary to work with OpenLDAP. It operates in a very similar way to Windows Active Directory, or AD. You can take this knowledge and populate your directory just like you did in Windows AD. If you're curious about the syntax of these commands, check out the supplemental reading on using LDIF files and LDAP commands. Again, if you're considering LDAP as your solution to your directory service needs, I'd recommend looking into the web manager tool PHPLDAP admin that we've included a link to in the next reading. Just like Windows AD, this topic can be pretty extensive. So think about which directory solution best fits the IT needs for your organization. There are lots of reasons why you might want to deploy the help of a directory service like OpenLDAP or Active Directory when working in a systems administration role. Directory services are great for centralized authentication, keeping track of where computers are in your organization, who can access them and more. Make sure to play around and familiarize with OpenLDAP or PHLDAP admin to get a better sense of how these directory services work. Checking out the official documentation is always a good place to start. By now, if you've learned about all the essential IT infrastructure services. The next topic we'll shift to is how to make sure all the hard work you've put in to your IT infrastructure doesn't go to waste by learning about disaster recovery and backups. Your hard work is really paying off, high five to that. Now take a moment to complete the quiz we put together for you, then we'll meet you back in the next video.
For information about the data interchange format, click here. https://en.wikipedia.org/wiki/LDAP_Data_Interchange_Format
For information about how to use LDIF files to make changes to an OpenLDAP system, click here. https://www.digitalocean.com/community/tutorials/how-to-use-ldif-files-to-make-changes-to-an-openldap-system

To Join this course click on the link below

maxresdefault (6).jpg

Google IT Support Professional Certificate http://bit.ly/2JONxKk

LInks to previous weeks Courses.

[Week 3] Google IT Support Professional Certificate #24 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2BRtOLu
[Week 2] Google IT Support Professional Certificate #23 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2N25GqA

[Week 1] Google IT Support Professional Certificate #22 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2PiJpX2
[Week 6] Google IT Support Professional Certificate #21 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2MqF857
[Week 5] Google IT Support Professional Certificate #20 | Course 3 WEEK 5 Operating Systems and You: Becoming a Power User
http://bit.ly/2P8wVRQ

[Week 4] Google IT Support Professional Certificate #19 || Course 3 WEEK 4 Operating Systems and You: Becoming a Power User
http://bit.ly/2B6KE8E

[Week 3] Google IT Support Professional Certificate #17 || Course 3 WEEK 3 Operating Systems and You: Becoming a Power User{Part 1}
http://bit.ly/2AYxJ8Z

[Week 2] Google IT Support Professional Certificate #16 || Course 3 WEEK 2 Operating Systems and You: Becoming a Power User
http://bit.ly/2nhSKBA

[Week 1] Google IT Support Professional Certificate #15 || Course 3 WEEK 1 Operating Systems and You: Becoming a Power User {Part 2}
http://bit.ly/2naOweX

[Week 1] Google IT Support Professional Certificate #14 || Course 3 WEEK 1 Operating Systems and You: Becoming a Power User {Part 1}
http://bit.ly/2M4pn3C

Google IT Support Professional Certificate #0 | Why you should do this Course? | All details before you join this course.
http://bit.ly/2Oe2t8p

#steemiteducation #Computerscience #education #Growwithgoogle #ITskills #systemadministration #itprofessional
#googleitsupportprofessional

Atlast If you are interested in the IT field, this course, or want to learn Computer Science. If you want to know whats in this course, what skills I learned Follow me @hungryengine. I will guide you through every step of this course and share my knowledge from this course daily.

Support me on this journey and I will always provide you with some of the best career knowledge in Computer Science field.