Active directory linux centos

👥 Как добавить Linux CentOS в домен Active Directory с помощью SSSD?

Многие онлайн-руководства показывают, как использовать Samba и Winbind для присоединения Linux к домену Active Directory.

В этой статье мы покажем альтернативный способ добавления компьютера или сервера Linux в домен с использованием realmd (Realm Discovery) и SSSD (System Security Services Daemon).

В этой статье мы покажем, как присоединить сервер CentOS 8.1 к вашему домену Active Directory (на основе Windows Server 2016).

Realmd позволяет настраивать аутентификацию и членство в домене (в AD или IPA / FreeIPA) без сложных настроек.

Информация о домене обнаруживается автоматически.

Realmd использует SSSD для аутентификации и проверки учетных записей пользователей.

Чтобы успешно присоединиться к домену Active Directory, вам необходимо выполнить следующие требования на вашем сервере CentOS:

• Настройте синхронизацию времени с контроллером домена Active Directory (и ваш DC с ролью PDC должен синхронизировать время с внешним NTP-сервером). В противном случае SSSD не сможет работать правильно. Этот сервис поддерживает только Kerberos (и не может использоваться для аутентификации с использованием NTLM). Соответственно, разница во времени между DC и Linux-клиентом не должна превышать 5 минут.
• В Linux Centos необходимо настроить DNS-клиент для использования службы DNS на контроллерах домена.

Установите клиент NTP (chrony) на CentOS:

Затем в файле конфигурации /etc/chrony.conf укажите полные доменные имена или IP-адреса серверов NTP для синхронизации (это могут быть контроллеры домена AD):

Запустите службу NTP и добавьте ее в автозапуск:

Теперь установите необходимые пакеты из репозитория CentOS:

Источник

Add Linux to Windows Domain using realm (CentOS/RHEL 7/8)

Table of Contents

Microsoft has its Identity Management suite to build around the Active Directory, and Red Hat has its identity management directory server. In this article I will share the steps to add Linux to Windows Active Directory Domain. The steps are validated by adding RHEL/CentOS 7 and 8 Linux to Windows Active Directory configured on Windows Server 2012 R2.

Some more articles on similar topic:

• How to join Linux client to Windows AD Domain using realmd with SSSD (CentOS/RHEL 7/8)
• How to join Linux client to Windows AD Domain using adcli with SSSD (CentOS/RHEL 7/8)
• How to join Linux client to Windows AD Domain using winbind (CentOS/RHEL 7/8)

1. Overview on realmd tool

RealmD is a tool that will easily configure network authentication and domain membership. With RHEL/CentOS 7, RealmD is fully supported and can be used to join IdM, AD, or Kerberos realms. The main advantage of using realmd is the ability to provide a simple one-line command to enroll into a domain as well as configure network authentication.

For example, realmd can easily configure:

The realmd system supports the following domain types:

• Microsoft Active Directory
• Red Hat Enterprise Linux Identity Management

The following domain clients are supported by realmd:

• SSSD for both RHEL/CentOS Identity Management and Microsoft Active Directory
• Winbind for Microsoft Active Directory

Following table lists some of the most used realm commands:

Command	Description
realm discover	Run a discovery scan for domains on the network.
realm join	Add the system to the specified domain.
realm leave	Remove the system from the specified domain.
realm list	List all configured domains for the system or all discovered and configured domains.
realm permit	Enable access for specified users or for all users within a configured domain to access the local system
realm deny	Restrict access for specified users or for all users within a configured domain to access the local system

2. Lab Environment

For demonstrations in this article to add Linux to Windows AD Domain on RHEL/CentOS 7/8, we will use two virtual machines running in an Oracle VirtualBox installed on my Linux Server virtualization environment.

We have a Microsoft Server 2012R2 Active Directory Domain Controller with the IP address 192.168.0.107 and the CentOS 8 host with the IP address 192.168.0.117 . In this article I will only cover the part to add Linux to Windows AD Domain on the client side. So this article to add Linux to Windows AD Domain requires a pre-configured Windows Active Directory.

3. Pre-requisites to add Linux to Windows AD Domain

3.1 Update /etc/resolv.conf

Make sure RHEL/CentOS client machine is able to resolve Active Directory servers. To do this update your /etc/resolv.conf with the IP address of your Domain Controller on your RHEL / CentOS 7/8 client host.

3.2 Verify Domain Name Resolution

Verify if the client is able to resolve the domain name:

Verify the configuration for name resolution. In particular, verify the DNS SRV records.

3.3 Install packages (RHEL/CentOS 7)

For minimal install servers, you need to install krb5-workstation package , which provides klist command. Install adcli package along with sssd :

• sssd: The System Security Services daemon can be used to divert client authentication as required
• adcli: These are the tools for joining and managing AD domains

3.4 Install packages (RHEL/CentOS 8)

Following list of packages are required for integrating Linux client to Windows domain using realm. We need oddjob oddjob-mkhomedir to make sure the home directory is automatically created for domain users.

4. Using realm to join Linux to Windows Domain

With all the packages installed, we can use the realm command to add Linux to Windows AD Domain and manage our enrolments. This command is part of the realmd package that we added.

4.1 List configured domains

We can use the list subcommand to ensure that we are not currently part of a domain:

The output should be blank.

4.2 Discover available domains in the network

Now, we are ready to proceed with the next step i.e. to add Linux to Windows AD Domain. With a simple environment, you will know the domain that you want to join; at least we certainly hope that you do . In our case, we do know it and this is golinuxcloud.com .

The realm discover command returns complete domain configuration and a list of packages that must be installed for the system to be enrolled in the domain.

4.3 Join Linux client to Windows domain

The realm join command then sets up the local machine for use with a specified domain by configuring both the local system services and the entries in the identity domain. The process run by realm join follows these steps:

• Running a discovery scan for the specified domain.
• Automatic installation of the packages required to join the system to the domain.
• Joining the domain by creating an account entry for the system in the directory.
• Creating the /etc/krb5.keytab host keytab file.
• Configuring the domain in SSSD and restarting the service.
• Enabling domain users for the system services in PAM configuration and the /etc/nsswitch.conf file.

Initially I was getting following error while trying to join my Linux client to Windows domain using realm:

In the journalctl logs I could find the following logs:

4.4 How to fix «KDC has no support for encryption type»?

Method-1
With RHEL/CentOS 8, rc4 is not in the DEFAULT crypto policy anymore, see man crypto-policies for details. Unfortunately it is still the common fallback in AD.

So we can add rc4-hmac in /etc/krb5.conf.d/crypto-policies as permitted_enctypes as shown below.

Now you can re-try to join Linux client to windows domain using realm:

Method-2
Here also we add rc4 encryption policy but instead of using /etc/krb5.conf.d/crypto-policies , we will add following content in a new file under / etc/krb5.conf.d/

Now you can try to join Linux client to the windows domain using realm:

Method-3
You can allow weak encryption by defining the following under [libdefaults] in /etc/krb5.conf file:

Now you can try to join Linux client to the windows domain using realm:

5. Verify if Linux client is integrated to windows domain

As a standard user, you can then list the domain you have joined using the realm list command again. We should note that the output at first may seem similar to the realm discover golinuxcloud.com command that we ran earlier; however, on closer examination, we will see that we are now a member server, as shown by configured: kerberos-member in the following command:

6. Configure NSS for SSSD service

Next we need to configure NSS to authenticate the users in the Linux client and create home directories for AD users:

6.1 On RHEL/CentOS 7

You can use authconfig on RHEL/CentOS 7 server to configure PAM and make sure the home directories of AD users are automatically created:

Next enable and start/restart oddjobd.service

6.2 On RHEL/CentOS 8

We will use authselect which is the new version of authconfig in RHEL/CentOS 8 for configuring PAM files and making sure that home directories of AD users are automatically created when they login to the Linux client:

Next enable and start/restart oddjobd.service

7. Login as Active Directory User on Linux Client

Let us try to login to our Linux client using Windows AD user and verify if the home directory is automatically created. But first we need to check if our Linux client is able to get the user details of AD users:

So our Administrator user from the AD is detected by the Linux client, so let’ try to switch user to Administrator:

As expected the home directory for our AD user was automatically created.

8. Leaving Active Directory domain

There will be occurrences where the Linux server needs to be removed from active directory domain. Often, this is the case where it is removed from one active directory domain before being added to another active directory domain. Should this be required, the realm command makes the process easy.

The additional option: —remove will ensure that the computer account is also deleted from the domain; otherwise, it should be deleted separately.

Summary

In this article we learned how we can join a Linux client (CentOS/RHEL 7/8) to Windows AD Domain using realmd tool. The realmd system provides a clear and simple way to discover and join identity domains. It does not connect to the domain itself but configures underlying Linux system services, such as SSSD or Winbind, to connect to the domain.

It can run a discovery search to identify available AD and Identity Management domains and then join the system to the domain, as well as set up the required client services used to connect to the given identity domain and manage user access. Additionally, because SSSD as an underlying service supports multiple domains, realmd can discover and support multiple domains as well.

Further Reading

You can go through the following articles to learn more about integrating Linux client to Windows domain using realmd
Using realmd to Connect to an Active Directory Domain
man page of krb5.conf [libdefaults]

Related Searches: linux login with active directory, join linux server to active directory, add linux server to windows domain, linux active directory authentication, how to add a linux system to a windows domain, linux windows domain authentication, linux ad integration

Related Posts

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

4 thoughts on “Add Linux to Windows Domain using realm (CentOS/RHEL 7/8)”

Is there any way to do this without revrting to the CLI?

You mean using any GUI based tool?

Hi, after doing above steps, I was able to do a domain join but I was unable to SSH to the linux server with AD user id.. any advise?

Источник

How to join a Linux system to an Active Directory domain

Posted: October 13, 2020 | by Edem Afenyo

Microsoft’s Active Directory (AD) is the go-to directory service for many organizations. If you and your team are responsible for a mixed Windows and Linux environment, then you probably would like to centralize authentication for both platforms. I’ll cover how to add Linux computers to an Active Directory domain.

Active Directory and the need for centralized access management

More Linux resources

Microsoft’s Active Directory, more popularly known as AD, has held the lion’s share of the market for enterprise access management for many years now. It is used by institutions and individuals the world over to centrally control access to resources belonging to the organization. It gives you the ability to manage users, passwords, resources such as computers, and dictate who has access to what. For some of you reading this write-up, especially those who work in large institutions, you have interacted with AD before. Usually, the interaction is using one set of login credentials to log in to any workstation in the organization. That is just the tip of a large iceberg.

Imagine a collection of 40 computer systems and 70 users in a firm. Some employees run shifts while others work regular hours. Some have access to printing; others don’t. The traditional way of working is to create local user accounts on each computer a user needs to access. Imagine the workload on the end-user support team. When a user changes his password for any reason, that user has to change the password on all computers he previously had access to, to keep things in sync. In no time, there will be mayhem. Now, imagine two members of the staff resign. I do not need to tell you the monotonous work that has to be repeated any time there’s a change to the staffing or any workstations. For IT teams, this is a nightmare. Time that could be used for innovative tasks is now spent reinventing the wheel. 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. Basically, AD is a kind of distributed database, which is accessed remotely via the Lightweight Directory Access Protocol (LDAP). LDAP is an open protocol for remotely accessing directory services over a connection-oriented medium such as TCP/IP. AD is not the only directory service based on the x.500 standard, or that can be accessed using LDAP. Other directory services include OpenLDAP and FreeIPA. However, AD is a mature Windows-based service that comes incorporated with Windows Server systems. 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. Directory services such as FreeIPA are Linux-based and provide an excellent service for a Linux stable. 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.

Pre-requisites

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:

• An account in AD that has the privileges necessary to join a system to the domain.
• A Linux server (a CentOS 7 server was used for this demonstration).
• A Domain Controller.
• Ensure your Linux server knows how to find the domain controller via DNS.

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.

• AD Domain Name: Hope.net
• User account for joining the domain: fkorea (Fullname — Fiifi Korea)
• Linux server hostname: centy2

Packages to install

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.

However, for those interested in the details, a quick Google search should be of great help.

Realmd (interacting with the domain)

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:

Supply the password when the prompt appears and wait for the process to end.

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.

Have a look at its output:

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.

To leave the domain altogether, you need two words: realm leave

Further configuration

So now that the Linux server is part of the AD domain, domain users can access the server with their usual credentials. We are done, right? Wrong. «What’s the problem?» I hear you say.

Well, for starters, this is the barebones configuration to get you up and running. But the experience is clunky, to say the least. We need to configure the service further to give it a true AD feel. It should be just like logging on to a domain-joined Windows 10 workstation.

Secondly, there is the big elephant in the room for sysadmins called Dynamic DNS Updates (DynDNS). If it is not set up correctly, we create extra overhead by having to maintain DNS records manually. For an environment that relies heavily on DNS, that could be a problem. For Windows systems, joining a system to the domain means two entries are automatically managed and maintained on the DNS server. When IP addresses change, the change is automatically reflected in DNS. This means you can change the IPs of systems without incurring the cost of manual maintenance. This will only make sense to people who already take advantage of DNS in their environments. Aside from the noticeable productivity gains of automation, it helps to have both Windows and Linux environments working the same way.

The third issue is DNS Scavenging. In an Active Directory domain, DNS is usually provided by the Domain Controllers. Every system joined to the domain has an automatic DNS entry with a corresponding IP address. This is super convenient. Automatically, at a specified interval, stale DNS records are deleted to prevent misdirected packets and also take care of deleted computer objects. This is known as scavenging, and it is not turned on by default in AD. However, if it is turned on, we need to configure it. Typically, the scavenging interval is seven days. If, after that period, there has been no update to the record, it is deleted, unless it is a static record. For Windows systems, the Dynamic Updates feature is automatically set up. However, with Linux servers, a few modifications need to be made. Without doing that, we will have services going down after a while because their records are deleted from DNS, and no one knows how to reach their component parts.

Now that we know some of the potential issues we need to address, let’s take a look at some of the things we can tweak to deliver a more seamless experience to the end-user and the sysadmin.

SSSD (easier logins and dynamic updates)

sssd on a Linux system is responsible for enabling the system to access authentication services from a remote source such as Active Directory. In other words, it is the primary interface between the directory service and the module requesting authentication services, realmd . Its main configuration file is located at /etc/sssd/sssd.conf . As a matter of fact, this is the main configuration file we will modify.

Let’s have a look at its contents before configuration. Once you join the domain, it is immediately modified to contain the minimum information required for a successful logon. My file looked like this:

In order to solve all three of the problems I mentioned earlier, edit your file to look like the one below:

Most of the options are self-explanatory, and you can modify yours accordingly while we step through what some of the key options represent. More information on all the options can be obtained by checking the man page. I think it is well written. Just type man 5 sssd.conf at the command line. You can also view the man page for sssd_ad for further information.

First and foremost, the configuration file is separated into two sections. The global section, under [sssd] and the domain-specific options section, [domain/[domain name]].

The global section contains options that affect the general behavior of sssd , such as the version information and related services. One key parameter under this section is shown below:

• default_domain_suffix — Set this to the domain name if you do not want to have to type the full user account name when logging in. Instead of having to type fkorea@hope.net always, you can just type fkorea and the password. This helps a lot when you have a long domain name.

The domain-specific section contains parameters that are specific to the domain you have joined. Key parameters are:

• access_provider — Allows you to select a provider optimized and used for interacting with AD servers for authentication purposes. It should be set to ad . Other values that can be used here are ldap and ipa , assuming you use those directory services.
• id_provider — Allows you to select a provider optimized and used for interacting with AD servers for identification purposes. It should be set to ad .
• ad_hostname — This should be the fully qualified hostname of the server. It should be set if the system’s hostname is anything other than the fully qualified domain name. If this is not set and the sssd does not have access to the fully qualified hostname, dynamic updates will fail.
• ad_domain — This should be the full domain name ( hope.net in this case).
• cache_credentials — This enables AD users to log in when the domain controller is offline. When this is set to true, credentials are cached for a period such that authentication does not fail when the back end is offline. The period of storage is also configurable.
• fallback_homedir — This helps you set a home directory for AD users who do not have a home directory attribute in AD. This is different from the override_home parameter that works when a home directory is set in AD for users.
• dyndns_update — This enables dynamic DNS updates and accepts either true or false as a value. When dynamic updates are enabled, updates occur primarily under three conditions:
  • When the Linux server restarts.
  • When the provider comes online.
  • When the refresh interval is due.
• dyndns_refresh_interval — This value is in seconds with a practical minimum of 60 seconds. It accepts integer values and has a default of 24 hours (86400s). In this example, we set it to 12 hours. If nothing else triggers an update, an update is regularly done between.
• dyndns_update_ptr — A boolean value that specifies whether the associated PTR record is to be updated in every update cycle. PTR records are used for reverse lookups, and unless there is a good reason, this should be set to true.
• dyndns_auth — Specifies whether the dynamic updates should be done securely or not. The setting depends on the mode accepted by AD. If AD is set to Accept Secure Updates Only, this value should be set to GSS-TSIG. If not, and you do not care for the security benefits of secure dynamic updates (despite the strong warning in AD), this value can be set to none.

Once the configuration is complete, restart sssd to apply settings immediately.

At this point, we are set. We can now login like we would at a Windows workstation or server.

Источник