This is my evaluation of Course IV, week 4 (total week 22) of the Google IT Support Professional Certification program on coursera.org. This week is all about directory services, used to unify policies for users and computers.
. . .
Introduction to Directory Services
We’ve already been through some important IT services—storage, communication, security, and software and platform services. The last IT infrastructure service we’re going to cover is directory services.
This looks like it is going to be a really long week, with almost 2 hours of video queued up.
What is a Directory Server?
A directory server provides a lookup service that tracks network resources and corresponding network addresses. It is kind of like a phone book.
An enterprise-level directory server should support replication, which means the data can be stored across multiple physical servers but still act like one unified system. This means that the system is protected from failures at one location, and also reduces latency while querying the data, as the “copy” in your location will be responding to your query.
A directory service should be accessible from many operating systems, as well as from different locations throughout the organization’s network.
Directory services are “useful for organizing data and making it searchable for an organization.”
This organization is built on the concept of a hierarchy of objects and containers. A container is referred to as an organizational unit (OU), and can contain objects or other OUs. This is just like the filesystems we’re used to, files inside directories inside directories, etc.
We see an example with the highest level is the domain, and two OUs below, Users and Computers. The Users OU contains three more OUs, one for Sales, one for Engineering, and one for Marketing. Each of these OUs contain all the users for that department.
This kind of organization allows you to easily implement polices throughout the organization, such as requiring stronger passwords for everyone in the engineering department.
Policies are also inherited from parent OUs, so that all members of each department will inherit changes made at the User level.
A sysadmin in charge of this server would be responsible for setting up and maintaining the server, including updating the OS that the server was running on. (I’m not sure why they point this out. Who else would be responsible?)
Depending on the organization, the design and implementation of this directory system may be up to one sysadmin or an entire team.
Implementing Directory Services
Directory services are an open network standard for compatibility among different software companies. These early “X.500” standards included protocols like Directory access Protocol (DAP), Directory System Protocol (DSP), Directory Information Shadowing Protocol (DISP), and Directory Operational Bindings Management Protocol, also quite seriously known as DOP.
An alternative to DAP was the Lightweight Directory Access Protocol, or LDAP. These are open standards and have been used by many different vendors.
Microsoft’s implementation is Active Directory, better known as AD, which is built for use in a Windows Server environment.
There are open-source directory services that use LDAP, as well, including OpenLDAP.
OpenLDAP supports many platforms, including Windows, UNIX, and Linux.
While AD is a server software, there is a client tool called Microsoft Office Active Directory Users and Computers, or ADUC.
There are many client applications used to interface with a directory server. Many are open source, and almost every OS is designed to work with a directory service. This allows central management of users and accounts.
What is Centralized Management?
Sysadmins are responsible for making things run smoothly. You might be responsible for making sure servers are kept up to date with security patches. Instead of going to each machine and doing updates one at a time, we can manage this work from centralized management services, which can “provide instructions to all of the different parts of [my] IT infrastructure.”
Directory services are one type of centralized management, offering authentication, authorization, and accounting, known as AAA. Your directory service grants or denies access to computers, file systems, and other resources throughout the network.
Most organizations have their IT resources available to users based on the role the user has in the organization. Anyone in a sysadmin role will have more access than someone in a data entry role.
Users will also be assigned to groups, giving them access according to what they need to do their job. A sysadmin may need access to everything, while a normal user may only need access to file shares, printers, and email.
When a user starts their job they will be assigned to a group. If they change jobs within the company, they just need to be assigned to a different group. This means a sysadmin doing their onboarding won’t have to go through and manually allow and deny permissions for that user, they just assign them to the group. This is called role-based access control, or RBAC.
The same way centralized management is used to control user access and groups, it can be used to control configuration management. Centralized configuration management allows you to create rules that determine how machines are setup.
A common way of deploying configurations is to write logon scripts, which run every time a user logs on and can be written to setup the machine for that user. We’ll go over some of this later in a segment on Active Directory and Group Policy Objects.
Reading: Centralized Management
What is LDAP?
LDAP (Lightweight Directory Access Protocol) is the underlying protocol of most modern directory services. It is used by both OpenLDAP and Active Directory.
Many different operations can be performed in LDAP, like creating new user objects in the directory server database or modifying existing ones. An LDAP “entry” is just a set of information used to describe something.
Here’s a breakdown of an example LDAP entry using LDAP notation:
Dn:CN=Homer J Simpson,OU=Sysadmin,DC=example,DC=com
- dn: distinguished name
- CN: common name of the object, in this case, the person’s name
- OU: is the organizational unit, in this case the group called “sysadmin”
- DC: domain component “example”
- DC: domain component “.com”
Reading: LDAP format.
What is LDAP Authentication
LDAP allows for different levels of access to directories, meaning that some can be “private” and others “public.”
We have discussed adding, removing, and modifying entries in LDAP directories. Another operation is the bind operation, which is used to authenticate clients to the directory server.
When logging into an website that uses LDAP, your client will send a bind request, containing your login credentials. This is then authenticated by the server and will grant you access when authenticated.
There are three ways to authenticate.
- Anonymous: Anonymous binding does not really authenticate anything.
- Simple: Only requires username and password. Usually sent in plaintext, not secure.
- SASL (Simple Authentication Security Layer): This binding method uses an encryption protocol like TLS to secure the operation, requiring the client and server to authenticate—usually by using Kerberos, a network authentication protocol “used to authenticate user identity, secure the transfer of user credentials, and more.”
Once a client has been authenticated by the LDAP server they are allowed to use the system according to their access level.
The original dog from hell,* now authenticating.
Heather Overcoming Obstacles
She sure did, folks. She sure did.
What is Active Directory
Active Directory (AD) is the native directory service for Windows and is used to centrally manage networks of computers and users. Active Directory is an important part of virtually all organizations running Windows fleets.
AD works similarly to LDAP, and is interoperable with Linux, OSX and other non-Windows systems.
AD not only provides directory services and centralized authentication for Windows fleets, it also acts as the central repository of group policy objects (GPOs). GPOs are used to govern the configuration of Windows computers.
Active Directory contains a multitude of tools and utilities. We’ll start with the Active Directory Administrative Center, or ADAC. ADAC is an important tool to understand, and is very useful while learning how things work in AD.
Directory services are hierarchical, just like filesystems. Everything in AD is an object, whether it is a container, which can contain other objects, or an organizational unit (OU), which is like a folder in a filesystem. There are some “default containers,” simply referred to as “containers,” which act as the default locations for some objects.
Containers cannot contain other containers, but OUs can contain other OUs.
ADAC is organized with a organizational tree on the left of the window, with many containers. The first node in the tree will be the domain, which will have a succinct name (such as “example”, as in this example) and will also be given a DNS name, like “example.com”. Computers in the domain (computers are objects) will be given a DNS name, as well.
This hierarchy within a domain is often referred to as a “tree.” A group of these trees, or domains, is referred to as a “forest.” A forest contains one or more domains, and accounts can share resources between domains in the same forest.
The next container in ADAC is Computers. A computer account is created when a machine is joined to the AD domain.
Next in ADAC is the container for Domain Controllers (DCs). They are created in this location in ADAC by default. A DC is a host of the AD database, and also acts as a DNS server to provide name resolution between servers and clients. DCs determine which users and computers are allowed to login to the domain. DCs are also used to determine if users have access to shared resources like file systems or printers. This means that sysadmins can make changes and have those changes propagate out through the network quickly.
Most DCs are configured as read-write replicas, which means that if a change is made on one DC, that change to the database is copied to all other DC databases. This is usually a quick process, and the latest change is usually the final result.
Some changes to the database can only be made by one DC at a time. Those changes are tasked to one DC, which has been designated a flexible single-master operations (FSMO) role.
The Users container in ADAC is where new AD users and groups are created by default.
For the AD system to function, machines must be bound to AD. This means that AD knows about the computer and has provisioned it an account, and that the computer knows about the AD domain and proceeds through authentication with it.
Reading: Active Directory
Here you go, some AD reading.
Managing Active Directory
Managing AD is an enormous topic, so here we go through some of the more common tasks you may encounter as a sysadmin in charge of managing Active Directory.
A new AD domain will have a default administrator user account, and many default user groups. Here’s a quick overview of the more important groups.
- Domain Admins: The administrators of the domain. The original administrator account will be a member of this group. These users can make any changes to the domain. Domain admins can also be local admins for any machine joined to the domain.
- Enterprise Admins: These are also domain admin accounts, and the default admin account will be a member of this group. They can also make changes to other domains in the forest. These accounts are rarely used except in unique situations, such as during upgrades to the forest.
- Users: This is every user account in the domain. If everyone needs access to, say, a fileshare, grant access to this group.
- Domain Computers: This group is all computers joined to the domain except for domain controllers.
- Domain Controllers: All DCs in the domain.
An important reminder here not to use your domain admin account as your daily account. There is too much power associated with this level account, and would put the entire domain at risk if it was used carelessly. If you need to perform certain tasks frequently, but don’t need to use the broad power of a domain admin account, you may be able to delegate permissions using ACLs on AD objects.
Managing Active Directory Users and Groups
This is an 11-minute video, which is probably about 3 times longer than average. It must be important.
User accounts are an important part of IT, and any sysadmin job will require understanding and managing user accounts and groups. Poor account management can either result in users not being able to do their jobs, or having more access than they require.
Here we’re going to create a user account for a new user in the default “Users” container in the Active Directory ADAC.
First, right-click on Users, New, and select User. This opens a dialog box to create a new user. It is required that you enter a user’s “Full Name,” which is their “real” name, as opposed to a username. AD calls the username the User SamAccountName, which means it is referencing the username and password database in Windows called the Security Account Manager, or SAM.
Every user account must have a unique name within that domain. There are some common conventions used in organizations for choosing usernames, like first initial and last name.
You will usually want to choose a temporary password for the user and be sure to select the “User must change password at next log on.” This means the first time they sign in they will be prompted to come up with their own password.
At the bottom of the ADAC window there is a “Windows PowerShell History” option, which allows you to view everything you just did in the ADAC GUI as corresponding PowerShell commands. You can see that the new user created corresponds to the line of LDAP notation under the cmdlet New-ADUser.
Now, lets create a group for our new user to join.
Right-click on the Users container again, select New and click on Group. This opens a Create Group dialog box. By default, ADAC will assign the same name you select for Group Name to the Group SamAccountName. Adding a description of the group will help people know what the group is for. Click OK and the new group will be created.
The new group now appears in ADAC.
There are two types of group in AD, Security Groups, and Distribution Groups. Security Groups allow access control to resources—they’re the groups we’ve covered so far. Distribution groups are used to organize accounts and contacts for email systems.
Group Scope determines how “group definitions are replicated across domains.”
A domain local scope is used to assign access to a resource, like a file share. You could have a domain local group for read access, and another for write access.
Global scope is used to organize accounts into roles. We just set up an example of a group with global scope.
Finally, there is universal scope, which is used to create replicated roles throughout an entire forest.
To add a user to a group, go to the ADAC and right-click on the user you would like to assign, and click on Add to group. In the Select Groups dialog box enter the name of the group in the Enter the object names to select field. Either click OK or click Check Names if you need to confirm the name of the group.
Again, you can check the PowerShell history to see that ADAC just took the user account, a Security Principal, and added it to the membership of the group.
You can also add a user to a group by opening ADAC, right-clicking the group, selecting Properties, and then clicking on the Members tab. To add a user, just click the Add button on the right and that will open the Add User dialog box. You can remove users from groups by doing the same thing and clicking on the Remove button.
Let’s say we just set up a group called “Researchers.” It may make sense to have them be part of a parent group for the entire department, called the “Research and Development Department.”
We can create a new group called Research and Development, with a global scope. Then, just add the Researchers group to the new Research and Development Group.
Reading: Group Security Principles
Managing Active Directory User Passwords
Central authentication helps immensely with managing passwords. We are presented here with the statistic that “25% of people forget their password at least once a day.” I don’t know what to make of that statistic. I use a password manager and thus only have one password to remember.
Password managements (resetting, mostly) is a large part of any helpdesk or IT support role.
Once a password is created in AD, it is turned into a one-way cryptographic hash, which we will cover more later. The basic concept is that a password can easily be turned into a hash, but a hash cannot as easily be turned back into a password. And if you were somehow able to find what was recorded in AD, you would not know the password, only the hash.
As a general rule, you should never know anyone else’s passwords. If more than one person can authenticate with a username and password, it makes auditing difficult or impossible. In this context, auditing means to learn who has access to what in your IT infrastructure.
Most password management as an IT support tech means resetting passwords. This should only be done when the person requesting the reset has permission to do so. Most organizations will have a policy or procedure in place to determine that the person making the request is who they say they are.
Let’s say Skippy has forgotten his password. Open the ADAC and right-click on the user’s account, then click Reset Password. This opens the Reset Password dialog, where you enter a new password. This will be a temporary password as long as the “User must change password at next log on” box is checked.
You will always want to make sure that you know and adhere to any policy in place at your organization.
If Skippy tried the wrong password too many times, Active Directory may lock the account until it is unlocked by an administrator. If the account has been locked, check the “unlock account” box in the Reset Password dialog box.
If a user is using the NTFS encrypted file system (EFS) they may lose access to that data when their password is reset.
Reading: EFS Features
Joining an Active Directory Domain
Computers can be joined to AD just like users. When a computer is bound to AD, it means two things: AD knows about the computer and has provisioned an account for it.
Windows computers by default are part of the Windows Workgroup, which are computers that can be networked but not centrally managed.
In the computer you are joining to AD, go to Control Panel\System and Security\System and click on Change Settings. This opens a System Properties dialog. Click Change, which will allow you to change the computer from a member of a Workgroup to a member of a domain. Enter the name of the domain, like example.com and click OK. The computer will then go out to the network to find a domain controller for example.com.
Once the DC is found, it will prompt for a username and password. You will probably be using you admin account, so enter that here. If the domain is called EXAMPLE then you will enter your username like “EXAMPLE\adminUserName”. Then click OK and your computer should then be joined to the domain.
Once we’re back in the ADAC open the Computers container and you should see that computer that just joined.
We can also join a computer to a domain using the CLI:
PS C:\Windows\system32> Add-Computer -DomainName ‘example.com’ -Server ‘dc1’ Cmdlet Add-Computer at command pipeline position 1 Supply Values for the following parameters: Credential
Now you are prompted for your admin credentials. Enter those, click OK and that’s it.
AD has gone through multiple iterations, and each release is known as a functional level. You will need to know the FL you are using and what features and capabilities it has. In ADAC you can right-click your domain, click properties to see what version you are using. In this example we see that the Functional Level is Windows Server 2016.
You can also see the FL in PowerShell:
PS C:\Windows\system32> Get-ADForest
PS C:\Windows\system32> Get-ADDomain
Reading: DFL and FFL
What is Group Policy?
Directory services use databases of objects, which represent things in the network that you can control. One type of object in AD is a group policy object, or GPO.
A GPO is “a set of policies and preferences that can be applied to a group of objects in the directory.” GPOs contain settings for user and computer accounts in AD.
Group policy allows you to easily configure access and software configurations for different departments or job titles.
You can create as many GPOs as needed, and they only take effect when they are linked to computers or users within that domain, site, or OU. When a GPO is linked, every computer or user in that OU will be subject to that policy.
A GPO can contain computer or user configurations, or both. Computer configurations are applied whenever the machine logs into the domain upon starting Windows. User configuration is applied when a user account is logged into the computer.
Policies are settings applied “every few minutes” and are not supposed to be changed by local admins.
Group policy preferences, however, are setting applied which may serve only as a template for configuration.
When a computer contacts a domain controller, the DC sends the machine a set of policies to be applied, and the computer downloads them from a folder called sysvol.
Many preferences and polices in GPOs correspond to values in the Windows Registry, the hierarchical database used by Windows to maintain application configuration data. A GPO in implemented by changing registry entries.
Group Policy Creation and Editing
Group policy creating and viewing is done through the Group Policy Management Console, or GPMC in AD. You can access it by running “gpmc.msc” (the video transcript incorrectly says “.mse”) from a command line.
GPMC is organized much like the ADAC and other tools in AD. There is a list of containers under the domain, including Default Domain Policy, Domain Controllers, Group Policy Objects, WMI Filters, and Starter GPOs.
All of the GPOs defined for this domain will be in the Group Policy Objects container. WMI Filters contains rules for targeting GPOs, using Windows Management Instrumentation properties to determine if a GPO should be applied to a specific computer.
Group Policy Result is a troubleshooting tool used to determine what policies apply to computers, users or groups in the network.
Group Policy Modeling is used to predict which group policies will apply to a computer or user. This is used to test implementations of new policies before they are deployed.
GPOs can only be linked to domains, sites, and OUs. That means that all users and computers should be in OUs so they can be easily targeted by GPOs.
A new AD environment there will be two default GPOs already created. These are the default domain controller policy and the default domain policy.
The default domain policy will apply to the entire domain, including all users and computers linked to the domain.
The default domain controller policy applies to any DCs linked to the domain.
As an example there is a settings report for Account Policies/Password Policy for the Default Domain Policy. It includes requirements of a 7-character minimum password length, a maximum password age of 42 days, and other settings.
There are thousands of settings to control with GPOs—a helpful resource is Microsoft’s Group Policy Settings Reference released with each edition of Windows Server.
Before creating a change to a policy, you can right-click on it and select Backup and save it in a secure location. Add a description to explain why you made the backup.
To change a policy, right-click on it in GPMC and select Edit. This opens the policy in the Group Policy management Editor. This shows the policy divided into two sections, Computer Configurations and User Configurations. Each of those has a Policies and Preferences subfolder.
It is important to understand that every GPO has access to all the settings that any other GPO does. There are no “special” GPOs. This means it is a best practice to use GPOs for specific categories of settings. It makes sense to have one GPO for domain-wide security settings and then another GPO for security settings for a specific department. Use specific GPOs for specific functions. You’ll be able to easily apply that policy only to the users and computers that require it.
When studying GPOs you can use the GPMC setting report as a “roadmap” to finding policies in the Group Policy Management Editor—all of the directories in the editor correspond to the hierarchy in the settings report.
Once you have found a policy you want to work with or understand, double-click it to view a Properties box, which has an Explain tab to help explain the policy.
If you make any changes to a GPO, clicking on Apply or OK will make the changes immediately. There is no Undo button for changing GPO. That’s why the backup feature is so important. To restore from a backup, go to the GPMC and right-click on the policy in the lefthand filetree and click on Restore from backup, then select the backup that you wisely made right before you ruined everything. The restore process will explain the changes you are undoing before you implement it.
Many organizations will have procedures in place for testing GPOs before implementing them.
One way to test policies is to create a special “test” OU within the OUs that it will be eventually applied to. Say we want to test a new GPO for the “RnD” department. I’ll create an OU within the RnD department and link some test machines to the domain in that OU, Vandelay.com\corporate HQ\RnD\Test. All the machines in the Test OU will fall under all existing GPOs, and can be subjected to any test GPOs you may wish to apply.
Creating a “test” GPO can be as easy as copying an existing one and pasting it and renaming it—something like “RnD_Test”. This gives you a duplicate policy that you can then mess with, without affecting the established policies you already have working.
Once you’ve created that test GPO, click the test container with all the test machines, right-click, and select Link New GPO and select the test GPO from the list.
Some organizations use add-on tools called AGPM, or Advanced Group Policy Management that enable more advanced control over these processes.
Group Policy Inheritance and Precedence
Because it is very easy to create layers and layers of overlapping GPOs, it is a best practice to create a strict, restrictive security policy and implement that as the default security policy for the entire domain.
Some users and computers may need exceptions to the default policy, so creating a GPO just for the OUs that contain those users or computers will allow you to manage the required security exceptions.
But what happens when a computer as conflicting policies applied to it? GPOs are applied based on a set of precedence rules. Because GPOs are applied to users and computers by using containers, GPOs that apply to the least specific or “largest” container are applied first, and those linked to the most specific or “smallest” container are applied last. First any GPOs linked at the AD site are applied, then any linked at the domain, and then any OUs from parent to child. If there are two conflicting polices, the most specific will be applied.
When you have more than one GPS applied to an OU, let’s say the RnD department, there is a Link Order assigned to the GPOs applied to that OU. The highest number in the link order is the lowest ranked GPO, so its settings are applied first.
“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.”
In the GPMC when viewing an OU, you can use the Linked Group Policy Objects tab to view the link order, and the Group Policy Inheritance tab to view the precedence of the GPOs applied to that OU. This summary does not show any site-based GPOs, because users and computers from different sites can be in the same OU.
When all group policies are “added up” for a machine and apply precedence rules to them this creates a Resultant Set of Policy (RSoP) for that machine. Comparing RSoPs is used in troubleshooting to compare machines.
In GPMC, right-click on Group Policy Results and open Group Policy Results Wizard. This will walk you through creating a RSoP for a computer and user. The RSoP will be created in the GPMC under the Group Policy Results node.
The RSoP is generated through the GPMC by making a remote connection to the selected computer. Remember that there is a myriad of ways that this connection can fail.
Group Policy Troubleshooting
If you’re working as a sysadmin in a Windows environment, you will be spending some time troubleshooting Active Directory problems.
One common problem is a user being unable to login to their computer or can’t authenticate to the AD domain. They may be typing the wrong password, they may have caps lock on, they may be locked out by AD, or some other setting may have been changed. It is always important to gather as much information as possible about the conditions under which the failure is happening.
Password lockout is always a common cause for authentication failure.
Another is the computer fails to contact a DC Is the computer networked to a DC? Is the DC functioning? Is there a DNS issue between the computer and the DC?
The computer will make a DNS request for the SRV records for the DC. If the DNS server doesn’t have SRV records that are requested it will not be able to contact the DC. The SRV record we’re looking for is:
_ldap._tcp.dc_msdcs.DOMAIN.NAME (DOMAIN.NAME is the DNS name of the domain.)
So we can open PowerShell and search for that SRV record:
PS C:\Users|Administrator> Resolve-DNSName -Type SRV -Name _ldap._tcp.dc_msdcs.example.com
This should output a NameTarget for each DC and include some info about it as well as an IP address. This indicates that DNS is functioning.
While it may depend on the configuration of your network, often after you login once to a computer and are authenticated, even if authentication subsequently fails you will be able to still login even if the network is disconnected.
Kerberos, the AD authentication protocol, is very sensitive to differences in system times. Domain computers are usually synchronized using the Windows Time Service, but this can fail and cause AD authentication to fail.
A common issue for in policy troubleshooting is when a GPO-defined policy or preference fails to apply. This will often be reported as something not working or something missing from someone’s computer, like software or a mapped network drive.
Sometimes, depending on configuration, the group policy engine may omit applying some types of policies in order to decrease logon times. This is called Fast Logon Optimization, and can cause GPO changes to be applied more slowly throughout the domain.
You can use the command
to push any changes out to all machines in the domain. You can also force every computer to reboot by adding /sync. Some types of GPOs can only be implemented when a machine first boots up.
Replication failure can also cause a GPO to not work as expected. This means that when a change is made to one DC, it has not properly gone out to other DCs, and therefore will not show up on machines connecting to those DCs.
To find the name of the DC a computer is connecting to you can use this command in PowerShell:
PS C:\Users\Administrator> $env:LOGONSERVER \\DC1 PS C:\Users\Administrator>
Or this in Command Prompt:
C:\Users\Administrator> echo %LOGONSERVER% \\DC1 C:\Users\Administrator>
You can check the overall status of group policy infrastructure from the GPMC by selecting the domain and looking at the Status tab. Click the Detect Now button to run a new analysis of the domain. Check that all domain controllers are running with replication in sync. If a DC has replication in progress, this could take some time to finish depending on the GPO infrastructure of your domain, or you may have a replication issue.
You can start troubleshooting a computer by running the RSoP either from the GPMC or directly from the computer. This creates a report in PowerShell:
PS C:\Users\Administrator> gpresult /R
And this creates a report that you can view as an HTML webpage:
PS C:\Users\Administrator> gpresult /H example.html
There are countless settings that can be misconfigured and cause problems you will need to troubleshoot. Countless. Is the GPO applied or denied? Was the GPO configured with an ACL set to something other than authenticated users? The list goes on forever so I’m not going to write it all out.
Do the reading up next!
Reading: Group Policy Troubleshooting
This is a big quiz with 15 questions. I had to take it a second time because I got a bunch wrong by not selecting all the answers that apply.
What is OpenLDAP?
OpenLDAP is a free and open source directory service. (LDAP stands for Lightweight Directory Access Protocol.)
LDAP functions much like Active Directory. LDAP notation, or LDAP data interchange format (LDIF) can be used to authenticate, add and remove users, groups, computers in a directory service.
OpenLDAP can be used on any OS, but our intrepid presenter recommends you use AD in a Windows environment. Hmmmmm… wonder why?
You can interact with OpenLDAP using the command line, or with tools like phpLDAPadmin, a web interface to manage LDAP data, similar to the AD GUI.
Here’s how to get OpenLDAP in a Linux environment:
lenny@snpp-workstation:~$ sudo apt-get install slapd ldap-utils
This will install the necessary packages and prompt you to create an admin password. Once it finishes installing you will want to reconfigure the slapd package to your needs:
lenny@snpp-workstation:~$ sudo dpkg-reconfigure slapd
This will ask a lot of questions about your setup, including DNS name for your domain, the name of your org, the admin password, databases, etc.
Once this is setup you have a running OpenLDAP server. Sweet.
Here are some useful commands to learn how to manage your OpenLDAP domain. To begin using commands, you’ll need to use LDIF files, which are simple text files containing values and attributes about… something. Here’s an example:
dn: uid=ralph,ou=Engineering,dc=example,dc=com objectClass: inetOrgPerson description: Ralph works in the Engineering department. cn: Ralph uid: ralph
The format looks weird at first, but we know that this “Ralph” character works in Engineering. I think “cn” stands for “common name” and “uid” stands for “user ID.”
Once the LDIF files are written, you can write commands to change settings.
- Ldapadd: “Takes the input of an LDIF file and adds the context of the files.”
- Ldapmodify: changes an existing object.
- Ldapdelete: remove the object that the LDIF refers to.
- Ldapsearch: searches the directory database for entries
At this point the video stops explaining the subject of managing OpenLDAP. The presenter explains that these are complicated topics, that using phpLDAPadmin is a good idea, that you can always learn the command syntax from official documentation. This point has been made nine thousand times in this program, but why not repeat it again?
If this material isn’t going to be taught, why make the video? There are some weird swings in content quality here, people. This has been a week with almost three times as much video as any other week, so it seems odd that there is this one really weak video thrown in. This could have been combined with the last video to make one video that is a minute longer.
Reading: Managing OpenLDAP
We get off lucky this week with just a ten-question quiz and no further assessments.