I have not even spoken about managing access to the printers. This is where a directory service such as Active Directory thrives. It can literally be a lifesaver. With Active Directory, each user is uniquely created as an object in a central database, with a single set of credentials.
Each computer system is also created as an object. Automatically, every user can access every workstation with that same set of credentials.
Any account changes that need to be made are made once at the central database. Members of staff can access the printers using the same set of credentials. The printers' authentication mechanism can be coupled with AD to achieve that. Happy users, happy IT team. Using groups and organizational units, access to various resources can be tailored and maintained. It gets even better. This directory can store staff phone numbers, email addresses, and can be extended to store other information.
What if someone resigns? No problem. Just disable the user's account. That person's access to all resources is nullified on the spot. The bigger the organization, the greater the need for centralized management. It saves time; it saves emotions. At its heart, a directory service is just an organized way of itemizing all the resources in an organization while facilitating easy access to those resources.
AD is not the only directory service based on the x. In other words, it's going to be the automatic winner when your organization has many Windows systems. This is one of the reasons for its ubiquity. When the rubber hits the road, the choice boils down to which of the two you can set up quickly, given your current environment and your team's skill set.
But what happens when you choose AD, and you have a few CentOS servers, and you do not want to maintain a separate set of credentials for your Linux users? That overhead is entirely avoidable. What you need to do is join the Linux servers to the AD domain, like you would a Windows server.
If that is what you need to do, then read on to find out just how to do it. It is possible to join a Windows system to a FreeIPA domain, but that is outside the scope of this article. This article presupposes that you have at least some introductory-level experience with Active Directory, especially around user and computer account management. Aside from that, the following obvious requirements need to be met:.
To make this article easier on everyone, here's a list of key details. This is how the lab I used for this write up is set up, so you should modify accordingly. For this configuration, the essential package to install is realmd. Aside from realmd , there are a host of packages that need to be installed to make this work. Realmd provides a simplified way to discover and interact with Active Directory domains. It employs sssd to do the actual lookups required for remote authentication and other heavy work of interacting with the domain.
In the interest of brevity, I won't dwell on the other packages in the list. Now that all packages have been installed, the first thing to do is to join the CentOS system to the Active Directory domain. We use the realm application for that. The realm client is installed at the same time as realmd. It is used to join, remove, control access, and accomplish many other tasks.
Here is the expected syntax for a simple domain join:. The space between the user account and the domain account is not a typo. By inserting the corresponding details, we get the following command:. Don't let the short absence of output deceive you. There are a number of operations that go on as part of the process.
You can tack on the -v switch for more verbose output. However, the best way to check if the computer is now a member of the domain is by running the realm list command. The command attempts to display the current state of the server with regard to the domain. It is a quick and dirty way to know which groups or users can access the server. It is also quite trivial to place the newly-created AD computer object in a specific Organizational Unit OU from the onset.
I'll leave that for further reading, but, as a tip, you can consult the man page. Using the realm client, you can grant or revoke access to domain users and groups.
A deep dive on using realmd in a more fine-grained way is enough to make another article. However, I will not be out of order to pick out a few parameters for your attention, namely client-software and the server-software. By now, you should understand why we had to install so many packages. So now that the Linux server is part of the AD domain, domain users can access the server with their usual credentials. Okay, here is the right information, by default any authenticated user has this right and can create up to 10 computer accounts in the domain.
If the user tries adding the 11th computer to the domain he gets the error. As per Microsoft users who have the Create Computer Objects permission on the Active Directory computers container can also create computer accounts in the domain. The difference is that users with permissions on the container are not restricted to the creation of only 10 computer accounts.
In addition, computer accounts that are created by means of Add workstations to domain have Domain Administrators as the owner of the computer account, while computer accounts that are created by means of permissions on the computers container have the creator as the owner of the computer account.
If a user has permissions on the container and also has the Add workstations to domain user right, the computer is added, based on the computer container permissions rather than on the user right. Login to the domain controller and launch the Group Policy Management console.
Right click the Default Domain Group policy and click Edit. Expand User Rights Assignment. On the right hand side double-click Add workstations to Domain policy.
Check the box Define these policy settings. Click Add User or Group and select the user or group. Click Apply and OK. Open the Active Directory Users and Computers snap-in. Right-click the container under which you want the computers to be added In this example I am choosing the Computers container and click on Delegate Control.
To add a user or group click Add. Once you are done click Next. Tasks to Delegate — Click Create a custom task to delegate. Click Next.
Choose Only the following objects in the folder and check the box Computer Objects. Often, when working with customers I see that their Active Directory domain join service account permissions are incorrectly configured. This article outlines the proper permissions you need to set to for an Active Directory domain join service account for use during the Windows OS deployment task sequence.
Also, domain admin accounts usually have access to many other Windows resources within the Active Directory domain. For these reasons and more, the least privilege account approach should always be used instead.
This helps avoid setting permissions on multiple OUs for each location.
0コメント