RHEL 8.5 - Integrating RHEL Systems Directly With Windows Active Directory
RHEL 8.5 - Integrating RHEL Systems Directly With Windows Active Directory
RHEL 8.5 - Integrating RHEL Systems Directly With Windows Active Directory
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is
available at
http://creativecommons.org/licenses/by-sa/3.0/
. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must
provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,
Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States
and other countries.
Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and
other countries.
Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the
official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks
or trademarks/service marks of the OpenStack Foundation, in the United States and other
countries and are used with the OpenStack Foundation's permission. We are not affiliated with,
endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
Abstract
This documentation collection provides instructions on how to integrate RHEL systems directly with
Windows Active Directory using SSSD.
Table of Contents
Table of Contents
. . . . . . . . . .OPEN
MAKING . . . . . . SOURCE
. . . . . . . . . .MORE
. . . . . . .INCLUSIVE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . .
. . . . . . . . . . . . . FEEDBACK
PROVIDING . . . . . . . . . . . . ON
. . . .RED
. . . . .HAT
. . . . .DOCUMENTATION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . .
.CHAPTER
. . . . . . . . . . 1.. .CONNECTING
. . . . . . . . . . . . . . . RHEL
. . . . . . SYSTEMS
. . . . . . . . . . .DIRECTLY
. . . . . . . . . . . TO
. . . .AD
. . . USING
. . . . . . . .SSSD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . .
1.1. OVERVIEW OF DIRECT INTEGRATION USING SSSD 5
1.2. SUPPORTED WINDOWS PLATFORMS FOR DIRECT INTEGRATION 6
1.3. ENSURING SUPPORT FOR COMMON ENCRYPTION TYPES IN AD AND RHEL 6
1.4. CONNECTING DIRECTLY TO AD 7
1.4.1. Discovering and joining an AD Domain using SSSD 7
1.4.2. Options for integrating with AD: using ID mapping or POSIX attributes 9
1.4.2.1. Automatically generate new UIDs and GIDs for AD users 9
1.4.2.2. Use POSIX attributes defined in AD 10
1.4.3. Connecting to AD using POSIX attributes defined in Active Directory 10
1.4.4. Connecting to multiple domains in different AD forests with SSSD 12
1.5. HOW THE AD PROVIDER HANDLES DYNAMIC DNS UPDATES 12
1.6. MODIFYING DYNAMIC DNS SETTINGS FOR THE AD PROVIDER 12
1.7. HOW THE AD PROVIDER HANDLES TRUSTED DOMAINS 13
1.8. REALM COMMANDS 14
.CHAPTER
. . . . . . . . . . 2.
. . CONNECTING
. . . . . . . . . . . . . . . .RHEL
. . . . . .SYSTEMS
. . . . . . . . . . DIRECTLY
. . . . . . . . . . . .TO
. . . AD
. . . .USING
. . . . . . .SAMBA
. . . . . . . . WINBIND
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
..............
2.1. OVERVIEW OF DIRECT INTEGRATION USING SAMBA WINBIND 15
2.2. SUPPORTED WINDOWS PLATFORMS FOR DIRECT INTEGRATION 15
2.3. ENSURING SUPPORT FOR COMMON ENCRYPTION TYPES IN AD AND RHEL 16
2.4. JOINING A RHEL SYSTEM TO AN AD DOMAIN 17
2.5. REALM COMMANDS 19
. . . . . . . . . . . 3.
CHAPTER . . MANAGING
. . . . . . . . . . . . . DIRECT
. . . . . . . . CONNECTIONS
. . . . . . . . . . . . . . . . .TO
. . . .AD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
..............
3.1. MODIFYING THE DEFAULT KERBEROS HOST KEYTAB RENEWAL INTERVAL 21
3.2. REMOVING A RHEL SYSTEM FROM AN AD DOMAIN 21
3.3. SETTING THE DOMAIN RESOLUTION ORDER IN SSSD TO RESOLVE SHORT AD USER NAMES 22
3.4. MANAGING LOGIN PERMISSIONS FOR DOMAIN USERS 23
3.4.1. Enabling access to users within a domain 23
3.4.2. Denying access to users within a domain 25
3.5. APPLYING GROUP POLICY OBJECT ACCESS CONTROL IN RHEL 26
3.5.1. How SSSD interprets GPO access control rules 26
3.5.1.1. Limitations on filtering by hosts 26
3.5.1.2. Limitations on filtering by groups 27
3.5.2. List of GPO settings that SSSD supports 27
3.5.3. List of SSSD options to control GPO enforcement 27
3.5.3.1. The ad_gpo_access_control option 27
3.5.3.2. The ad_gpo_implicit_deny option 28
3.5.4. Changing the GPO access control mode 29
3.5.5. Creating and configuring a GPO for a RHEL host in the AD GUI 30
3.5.6. Additional resources 31
.CHAPTER
. . . . . . . . . . 4.
. . .ACCESSING
. . . . . . . . . . . . .AD
. . . WITH
. . . . . .A
. . MANAGED
. . . . . . . . . . . .SERVICE
. . . . . . . . . ACCOUNT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
..............
4.1. THE BENEFITS OF A MANAGED SERVICE ACCOUNT 32
4.2. CONFIGURING A MANAGED SERVICE ACCOUNT FOR A RHEL HOST 32
4.3. UPDATING THE PASSWORD FOR A MANAGED SERVICE ACCOUNT 35
4.4. MANAGED SERVICE ACCOUNT SPECIFICATIONS 35
4.5. OPTIONS FOR THE ADCLI CREATE-MSA COMMAND 36
1
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
2
MAKING OPEN SOURCE MORE INCLUSIVE
The word master is being replaced with more precise language, depending on the context:
3
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
1. Make sure you are viewing the documentation in the Multi-page HTML format. In addition,
ensure you see the Feedback button in the upper right corner of the document.
2. Use your mouse cursor to highlight the part of text that you want to comment on.
3. Click the Add Feedback pop-up that appears below the highlighted text.
3. Fill in the Description field with your suggestion for improvement. Include a link to the
relevant part(s) of documentation.
4
CHAPTER 1. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SSSD
Connecting directly to AD
realm commands
Active Directory
NOTE
Direct integration with SSSD works only within a single AD forest by default.
The most convenient way to configure SSSD to directly integrate a Linux system with AD is to use the
realmd service. It allows callers to configure network authentication and domain membership in a
standard way. The realmd service automatically discovers information about accessible domains and
realms and does not require advanced configuration to join a domain or realm.
You can use SSSD for both direct and indirect integration with AD and it allows you to switch from one
integration approach to another. Direct integration is a simple way to introduce RHEL systems to an AD
environment. However, as the share of RHEL systems grows, your deployments usually need a better
centralized management of the identity-related policies such as host-based access control, sudo, or
SELinux user mappings. Initially, you can maintain the configuration of these aspects of the RHEL
systems in local configuration files. However, with a growing number of systems, distribution and
management of the configuration files is easier with a provisioning system such as Red Hat Satellite.
5
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
When direct integration does not scale anymore, you should consider indirect integration. For more
information on moving from direct integration (RHEL clients are in the AD domain) to indirect
integration (IdM with trust to AD), see Moving RHEL clients from AD domain to IdM Server.
For more information on which type of integration fits your use case, see Deciding between indirect and
direct integration.
Additional resources
Forest functional level range: Windows Server 2008 - Windows Server 2016
Domain functional level range: Windows Server 2008 - Windows Server 2016
Direct integration has been tested on the following supported operating systems:
NOTE
Windows Server 2019 does not introduce a new functional level. The highest functional
level Windows Server 2019 uses is Windows Server 2016.
RC4 encryption has been deprecated and disabled by default, as it is considered less secure than the
newer AES-128 and AES-256 encryption types. In contrast, Active Directory (AD) user credentials and
trusts between AD domains support RC4 encryption and they might not support AES encryption types.
Without any common encryption types, communication between RHEL hosts and AD domains might not
work, or some AD accounts might not be able to authenticate. To remedy this situation, modify one of
the following configurations:
Enable AES encryption support in Active Directory (recommended option): To ensure trusts
between AD domains in an AD forest support strong AES encryption types, see the following
Microsoft article: AD DS: Security: Kerberos "Unsupported etype" error when accessing a
resource in a trusted domain
6
CHAPTER 1. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SSSD
Enable RC4 support in RHEL: On every RHEL host where authentication against AD Domain
Controllers takes place:
IMPORTANT
The AD-SUPPORT cryptographic subpolicy is only available on RHEL 8.3 and newer.
To enable support for RC4 in RHEL 8.2, create and enable a custom
cryptographic module policy with cipher = RC4-128+. For more details, see
Customizing system-wide cryptographic policies with policy modifiers .
To enable support for RC4 in RHEL 8.0 and RHEL 8.1, add +rc4 to the
permitted_enctypes option in the /etc/crypto-policies/back-ends/krb5.config
file:
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-
192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-
sha256-128 camellia128-cts-cmac +rc4
Additional resources
For more information on working with RHEL cryptographic policies, see Using system-wide
cryptographic policies in the Security Hardening guide.
Prerequisites
Ensure that the following ports on the RHEL host are open and accessible to the AD domain
7
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Ensure that the following ports on the RHEL host are open and accessible to the AD domain
controllers.
Table 1.1. Ports Required for Direct Integration of Linux Systems into AD Using SSSD
Ensure that you are using the AD domain controller server for DNS.
Verify that the system time on both systems is synchronized. This ensures that Kerberos is able
to work correctly.
Procedure
2. To display information for a specific domain, run realm discover and add the name of the
domain you want to discover:
The realmd system uses DNS SRV lookups to find the domain controllers in this domain
8
CHAPTER 1. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SSSD
The realmd system uses DNS SRV lookups to find the domain controllers in this domain
automatically.
NOTE
The realmd system can discover both Active Directory and Identity Management
domains. If both domains exist in your environment, you can limit the discovery
results to a specific type of server using the --server-software=active-directory
option.
3. Configure the local RHEL system with the realm join command. The realmd suite edits all
required configuration files automatically. For example, for a domain named ad.example.com:
Verification steps
Additional resources
1.4.2. Options for integrating with AD: using ID mapping or POSIX attributes
Linux and Windows systems use different identifiers for users and groups:
Linux uses user IDs (UID) and group IDs (GID). See Introduction to managing user and group
accounts in Configuring Basic System Settings . Linux UIDs and GIDs are compliant with the
POSIX standard.
IMPORTANT
After connecting a RHEL system to AD, you can authenticate with your AD username and
password. Do not create a Linux user with the same name as a Windows user, as duplicate
names might cause a conflict and interrupt the authentication process.
To authenticate to a RHEL system as an AD user, you must have a UID and GID assigned. SSSD provides
the option to integrate with AD either using ID mapping or POSIX attributes. The default is to use ID
mapping.
SSSD can use the SID of an AD user to algorithmically generate POSIX IDs in a process called ID
mapping. ID mapping creates a map between SIDs in AD and IDs on Linux.
9
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
When SSSD detects a new AD domain, it assigns a range of available IDs to the new domain.
When an AD user logs in to an SSSD client machine for the first time, SSSD creates an entry for
the user in the SSSD cache, including a UID based on the user’s SID and the ID range for that
domain.
Because the IDs for an AD user are generated in a consistent way from the same SID, the user
has the same UID and GID when logging in to any Red Hat Enterprise Linux system.
NOTE
When all client systems use SSSD to map SIDs to Linux IDs, the mapping is consistent. If
some clients use different software, choose one of the following:
AD can create and store POSIX attributes, such as uidNumber, gidNumber, unixHomeDirectory, or
loginShell.
When using ID mapping described above, SSSD creates new UIDs and GIDs, which overrides the values
defined in AD. To keep the AD-defined values, you must disable ID mapping in SSSD.
Prerequisites
Ensure that the following ports on the RHEL host are open and accessible to the AD domain
controllers.
Table 1.2. Ports Required for Direct Integration of Linux Systems into AD Using SSSD
10
CHAPTER 1. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SSSD
Ensure that you are using the AD domain controller server for DNS.
Verify that the system time on both systems is synchronized. This ensures that Kerberos is able
to work correctly.
Procedure
2. Configure the local RHEL system with ID mapping disabled using the realm join command with
the --automatic-id-mapping=no option. The realmd suite edits all required configuration files
automatically. For example, for a domain named ad.example.com:
3. If you already joined a domain, you can manually disable ID Mapping in SSSD:
rm -f /var/lib/sss/db/*
d. Restart SSSD:
SSSD now uses POSIX attributes from AD, instead of creating them locally.
NOTE
11
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Verification steps
Additional resources
For further details about ID mapping and the ldap_id_mapping parameter, see the sssd-
ldap(8) man page.
By default, the SSSD service refreshes a RHEL client’s DNS record at the following intervals:
NOTE
If you set the dyndns_refresh_interval option to the same interval as the DHCP
lease, you can update the DNS record after the IP lease is renewed.
SSSD sends dynamic DNS updates to the AD server using Kerberos/GSSAPI for DNS (GSS-TSIG). This
means that you only need to enable secure connections to AD.
Additional resources
Prerequisites
You have joined a RHEL host to an Active Directory environment with the SSSD service.
12
CHAPTER 1. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SSSD
Procedure
2. Add the following options to the [domain] section for your AD domain to set the DNS record
refresh interval to 12 hours, disable updating PTR records, and set the DNS record Time To Live
(TTL) to 1 hour.
[domain/ad.example.com]
id_provider = ad
...
dyndns_refresh_interval = 43200
dyndns_update_ptr = false
dyndns_ttl = 3600
NOTE
You can disable dynamic DNS updates by setting the dyndns_update option in the
sssd.conf file to false:
[domain/ad.example.com]
id_provider = ad
...
dyndns_update = false
Additional resources
SSSD only supports domains in a single AD forest. If SSSD requires access to multiple domains
from multiple forests, consider using IPA with trusts (preferred) or the winbindd service instead
of SSSD.
By default, SSSD discovers all domains in the forest and, if a request for an object in a trusted
domain arrives, SSSD tries to resolve it.
If the trusted domains are not reachable or geographically distant, which makes them slow, you
can set the ad_enabled_domains parameter in /etc/sssd/sssd.conf to limit from which trusted
domains SSSD resolves objects.
13
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
By default, you must use fully-qualified user names to resolve users from trusted domains.
Additional resources
Controlling which domain users are allowed to access local system resources.
In realmd use the command line tool realm to run commands. Most realm commands require the user
to specify the action that the utility should perform, and the entity, such as a domain or user account,
for which to perform the action.
Command Description
Realm Commands
Login Commands
permit Enable access for specific users or for all users within
a configured domain to access the local system.
For more information about the realm commands, see the realm(8) man page.
14
CHAPTER 2. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SAMBA WINBIND
realm commands
You can use the realmd service to configure Samba Winbind by:
Note that:
Remote forests must trust the local forest to ensure that the idmap_ad plug-in handles remote
forest users correctly.
Samba’s winbindd service provides an interface for the Name Service Switch (NSS) and enables
domain users to authenticate to AD when logging into the local system.
Using winbindd provides the benefit that you can enhance the configuration to share directories and
printers without installing additional software. For further detail, see the section about Using Samba as a
server in the Deploying Different Types of Servers Guide .
Additional resources
15
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Forest functional level range: Windows Server 2008 - Windows Server 2016
Domain functional level range: Windows Server 2008 - Windows Server 2016
Direct integration has been tested on the following supported operating systems:
NOTE
Windows Server 2019 does not introduce a new functional level. The highest functional
level Windows Server 2019 uses is Windows Server 2016.
RC4 encryption has been deprecated and disabled by default, as it is considered less secure than the
newer AES-128 and AES-256 encryption types. In contrast, Active Directory (AD) user credentials and
trusts between AD domains support RC4 encryption and they might not support AES encryption types.
Without any common encryption types, communication between RHEL hosts and AD domains might not
work, or some AD accounts might not be able to authenticate. To remedy this situation, modify one of
the following configurations:
Enable AES encryption support in Active Directory (recommended option): To ensure trusts
between AD domains in an AD forest support strong AES encryption types, see the following
Microsoft article: AD DS: Security: Kerberos "Unsupported etype" error when accessing a
resource in a trusted domain
Enable RC4 support in RHEL: On every RHEL host where authentication against AD Domain
Controllers takes place:
IMPORTANT
16
CHAPTER 2. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SAMBA WINBIND
IMPORTANT
The AD-SUPPORT cryptographic subpolicy is only available on RHEL 8.3 and newer.
To enable support for RC4 in RHEL 8.2, create and enable a custom
cryptographic module policy with cipher = RC4-128+. For more details, see
Customizing system-wide cryptographic policies with policy modifiers .
To enable support for RC4 in RHEL 8.0 and RHEL 8.1, add +rc4 to the
permitted_enctypes option in the /etc/crypto-policies/back-ends/krb5.config
file:
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-
192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-
sha256-128 camellia128-cts-cmac +rc4
Additional resources
For more information on working with RHEL cryptographic policies, see Using system-wide
cryptographic policies in the Security Hardening guide.
Procedure
1. If your AD requires the deprecated RC4 encryption type for Kerberos authentication, enable
support for these ciphers in RHEL:
3. To share directories or printers on the domain member, install the samba package:
# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
17
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Adds the winbind module for user and group lookups to the /etc/nsswitch.conf file
Updates the Pluggable Authentication Module (PAM) configuration files in the /etc/pam.d/
directory
Starts the winbind service and enables the service to start when the system boots
6. Optionally, set an alternative ID mapping back end or customized ID mapping settings in the
/etc/samba/smb.conf file. For details, see the Understanding and configuring Samba ID
mapping section in the Deploying different types of servers documentation.
[plugins]
localauth = {
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
enable_only = winbind
}
IMPORTANT
To enable Samba to query domain user and group information, the winbind
service must be running before you start smb.
9. If you installed the samba package to share directories and printers, enable and start the smb
service:
Verification steps
3. Optionally, verify that you can use domain users and groups when you set permissions on files
and directories. For example, to set the owner of the /srv/samba/example.txt file to
AD\administrator and the group to AD\Domain Users:
18
CHAPTER 2. CONNECTING RHEL SYSTEMS DIRECTLY TO AD USING SAMBA WINBIND
# kinit administrator@AD.EXAMPLE.COM
# klist
Ticket cache: KCM:0
Default principal: administrator@AD.EXAMPLE.COM
# wbinfo --all-domains
BUILTIN
SAMBA-SERVER
AD
Additional resources
If you do not want to use the deprecated RC4 ciphers, you can enable the AES encryption type
in AD. See Enabling the AES encryption type in Active Directory using a GPO in the Deploying
different types of servers documentation.
For further details about the realm utility, see the realm(8) man page.
Controlling which domain users are allowed to access local system resources.
In realmd use the command line tool realm to run commands. Most realm commands require the user
to specify the action that the utility should perform, and the entity, such as a domain or user account,
for which to perform the action.
Command Description
Realm Commands
19
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Command Description
Login Commands
permit Enable access for specific users or for all users within
a configured domain to access the local system.
For more information about the realm commands, see the realm(8) man page.
20
CHAPTER 3. MANAGING DIRECT CONNECTIONS TO AD
Prerequisites
You have connected your RHEL system to the Active Directory domain.
The default renewal interval is 30 days. To change the default, follow the steps in this procedure.
Procedure
ad_maximum_machine_account_password_age = value_in_days
2. Restart SSSD:
Additional resources
Procedure
1. Remove a system from an identity domain using the realm leave command. The command
removes the domain configuration from SSSD and the local system.
NOTE
21
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
NOTE
When a client leaves a domain, the account is not deleted from AD; the local client
configuration is only removed. If you want to delete the AD account, run the
command with the --remove option. You are prompted for your user password
and you must have the rights to remove an account from Active Directory.
2. Use the -U option with the realm leave command to specify a different user to remove a
system from an identity domain.
By default, the realm leave command is executed as the default administrator. For AD, the
administrator account is called Administrator. If a different user was used to join to the domain,
it might be required to perform the removal as that user.
The command first attempts to connect without credentials, but it prompts for a password if required.
Verification steps
Additional resources
This procedure sets the domain resolution order in the SSSD configuration so you can resolve AD users
and groups using short names, like ad_username. This example configuration searches for users and
groups in the following order:
22
CHAPTER 3. MANAGING DIRECT CONNECTIONS TO AD
Prerequisites
You have used the SSSD service to connect the RHEL host directly to AD.
Procedure
Verification Steps
Verify you can retrieve user information for a user from the first domain using only a short name.
If a domain applies client-side access control, you can use the realmd to configure basic allow or deny
access rules for users from that domain.
NOTE
Access rules either allow or deny access to all services on the system. More specific
access rules must be set on a specific system resource or in the domain.
IMPORTANT
23
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
IMPORTANT
It is safer to only allow access to specific users or groups than to deny access to some,
while enabling it to everyone else. Therefore, it is not recommended to allow access to all
by default while only denying it to specific users with realm permit -x. Instead, Red Hat
recommends maintaining a default no access policy for all users and only grant access to
selected users using realm permit.
Prerequisites
Procedure
Currently, you can only allow access to users in primary domains and not to users in trusted domains.
This is due to the fact that user login must contain the domain name and SSSD cannot currently provide
realmd with information about available child domains.
Verification steps
$ ssh aduser01@example.com@server_name
[aduser01@example.com@server_name ~]$
2. Use the ssh command a second time to access the same server, this time as the
aduser02@example.com user:
$ ssh aduser02@example.com@server_name
Authentication failed.
Notice how the aduser02@example.com is denied access to the system. You have granted the
permission to log in to the system to the aduser01@example.com user only. All other users from that
Active Directory domain are rejected because of the specified login policy.
NOTE
If you set use_fully_qualified_names to true in the sssd.conf file, all requests must use
the fully qualified domain name. However, if you set use_fully_qualified_names to false,
it is possible to use the fully-qualified name in the requests, but only the simplified
version is displayed in the output.
Additional resources
24
CHAPTER 3. MANAGING DIRECT CONNECTIONS TO AD
IMPORTANT
It is safer to only allow access to specific users or groups than to deny access to some,
while enabling it to everyone else. Therefore, it is not recommended to allow access to all
by default while only denying it to specific users with realm permit -x. Instead, Red Hat
recommends maintaining a default no access policy for all users and only grant access to
selected users using realm permit.
Prerequisites
Procedure
This command prevents realm accounts from logging into the local machine. Use realm permit
to restrict login to specific accounts.
Verification steps
25
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
$ ssh aduser01@example.net@server_name
Authentication failed.
NOTE
If you set use_fully_qualified_names to true in the sssd.conf file, all requests must use
the fully qualified domain name. However, if you set use_fully_qualified_names to false,
it is possible to use the fully-qualified name in the requests, but only the simplified
version is displayed in the output.
Additional resources
The following sections describe how you can manage GPOs in your environment:
Section 3.5.5, “Creating and configuring a GPO for a RHEL host in the AD GUI”
SSSD maps AD Windows Logon Rights to Pluggable Authentication Module (PAM) service names to
enforce those permissions in a GNU/Linux environment.
As an AD Administrator, you can limit the scope of GPO rules to specific users, groups, or hosts by listing
them in a security filter.
RHEL 8.3.0 and newer: SSSD supports users, groups, and hosts in security filters.
RHEL versions older than 8.3.0: SSSD ignores host entries and only supports users and groups
in security filters.
To ensure that SSSD applies GPO-based access control to a specific host, create a new
26
CHAPTER 3. MANAGING DIRECT CONNECTIONS TO AD
Organizational Unit (OU) in the AD domain, move the system to the new OU, and then link the
GPO to this OU.
SSSD currently does not support Active Directory’s built-in groups, such as Administrators with
Security Identifier (SID) S-1-5-32-544. Red Hat recommends against using AD built-in groups in AD
GPOs targeting RHEL hosts.
Additional resources
For a list of Windows GPO options and their corresponding SSSD options, see List of GPO
settings that SSSD supports.
For more information on these sssd.conf settings, such as the Pluggable Authentication
Module (PAM) services that map to GPO options, see the sssd-ad(5) Manual page entry.
You can set the ad_gpo_access_control option in the /etc/sssd/sssd.conf file to choose between
three different modes in which GPO-based access control operates.
27
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Value of Behavior
ad_gpo_access_control
permissive GPO-based access control rules are evaluated but not enforced; a
syslog message is recorded every time access would be denied.
This is the default setting in RHEL 7.
This mode is ideal for testing policy adjustments while allowing
users to continue logging in.
The ad_gpo_implicit_deny option is set to False by default. In this default state, users are allowed
access if applicable GPOs are not found. If you set this option to True, you must explicitly allow users
access with a GPO rule.
You can use this feature to harden security, but be careful not to deny access unintentionally. Red Hat
recommends testing this feature while ad_gpo_access_control is set to permissive.
The following two tables illustrate when a user is allowed or rejected access based on the allow and deny
login rights defined on the AD server-side and the value of ad_gpo_implicit_deny.
28
CHAPTER 3. MANAGING DIRECT CONNECTIONS TO AD
Additional resources
For the procedure to change the GPO enforcement mode in SSSD, see Changing the GPO
access control mode.
For more details on each of the different GPO modes of operation, see the
ad_gpo_access_control entry in the sssd-ad(5) Manual page.
In this example, you will change the GPO operation mode from enforcing (the default) to permissive
for testing purposes.
IMPORTANT
If you see the following errors, Active Directory users are unable to log in due to GPO-
based access controls:
In /var/log/secure:
In /var/log/sssd/sssd__example.com_.log:
Prerequisites
29
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
Procedure
[domain/example.com]
ad_gpo_access_control=permissive
...
Additional resources
For the list of different GPO access control modes, see List of SSSD options to control GPO
enforcement.
3.5.5. Creating and configuring a GPO for a RHEL host in the AD GUI
The following procedure creates a Group Policy Object (GPO) in the Active Directory (AD) graphical
user interface (GUI) to control logon access to a RHEL host.
Prerequisites
Procedure
1. Within Active Directory Users and Computers, create an Organizational Unit (OU) to
associate with the new GPO:
b. Choose New.
2. Click on the name of the Computer Object that represents the RHEL host (created when it
joined Active Directory) and drag it into the new OU. By having the RHEL host in its own OU,
the GPO targets this host.
3. Within the Group Policy Management Editor, create a new GPO for the OU you created:
a. Expand Forest.
30
CHAPTER 3. MANAGING DIRECT CONNECTIONS TO AD
a. Expand Forest.
b. Expand Domains.
4. Specify a name for the new GPO, such as Allow SSH access or Allow Console/GUI access
and click OK.
e. Select Policies.
b. Double-click on Allow log on through Remote Desktop Services to grant SSH access.
7. Add the user(s) you would like to access either of these policies to the policies themselves:
c. Click OK.
Additional resources
For more details on Group Policy Objects, see Group Policy Objects in Microsoft
documentation.
31
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
For example, if the AD domain production.example.com has a one-way trust relationship with the
lab.example.com AD domain, the following conditions apply:
The lab domain trusts users and hosts from the production domain.
The production domain does not trust users and hosts from the lab domain.
This means that a host joined to the lab domain, such as client.lab.example.com, cannot access
resources from the production domain through the trust.
If you want to create an exception for the client.lab.example.com host, you can use the adcli utility to
create a MSA for the client host in the production.example.com domain. By authenticating with the
Kerberos principal of the MSA, you can perform secure LDAP searches in the production domain from
the client host.
NOTE
32
CHAPTER 4. ACCESSING AD WITH A MANAGED SERVICE ACCOUNT
NOTE
If you need to access AD resources from a RHEL host, Red Hat recommends that you join
the RHEL host to the AD domain with the realm command. See Connecting RHEL
systems directly to AD using SSSD.
You cannot join the RHEL host to the AD domain, and you want to create an
account for that host in AD.
You have joined the RHEL host to an AD domain, and you need to access another
AD domain where the host credentials from the domain you have joined are not
valid, such as with a one-way trust.
Prerequisites
Ensure that the following ports on the RHEL host are open and accessible to the AD domain
controllers.
You have the password for an AD Administrator that has rights to create MSAs in the
production.example.com domain.
You have root permissions that are required to run the adcli command, and to modify the
/etc/sssd/sssd.conf configuration file..
(Optional) You have the krb5-workstation package installed, which includes the klist diagnostic
utility.
Procedure
2. Display information about the MSA from the Kerberos keytab that was created. Make note of
the MSA name:
33
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
---- ------------------------------------------------------------
2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
2 CLIENT!S3A$@PRODUCTION.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
3. Open the /etc/sssd/sssd.conf file and choose the appropriate SSSD domain configuration to
add:
If the MSA corresponds to an AD domain from a different forest, create a new domain
section named [domain/<name_of_domain>], and enter information about the MSA and
the keytab. The most important options are ldap_sasl_authid, ldap_krb5_keytab, and
krb5_keytab:
[domain/production.example.com]
ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
krb5_keytab = /etc/krb5.keytab.production.example.com
ad_domain = production.example.com
krb5_realm = PRODUCTION.EXAMPLE.COM
access_provider = ad
...
If the MSA corresponds to an AD domain from the local forest, create a new sub-domain
section in the format [domain/root.example.com/sub-domain.example.com], and enter
information about the MSA and the keytab. The most important options are
ldap_sasl_authid, ldap_krb5_keytab, and krb5_keytab:
[domain/ad.example.com/production.example.com]
ldap_sasl_authid = CLIENT!S3A$@PRODUCTION.EXAMPLE.COM
ldap_krb5_keytab = /etc/krb5.keytab.production.example.com
krb5_keytab = /etc/krb5.keytab.production.example.com
ad_domain = production.example.com
krb5_realm = PRODUCTION.EXAMPLE.COM
access_provider = ad
...
Verification steps
Verify you can retrieve a Kerberos ticket-granting ticket (TGT) as the MSA:
In AD, verify you have an MSA for the host in the Managed Service Accounts Organizational Unit
(OU).
Additional resources
34
CHAPTER 4. ACCESSING AD WITH A MANAGED SERVICE ACCOUNT
Prerequisites
You have previously created an MSA for a host in the production.example.com AD domain.
(Optional) You have the krb5-workstation package installed, which includes the klist diagnostic
utility.
Procedure
1. (Optional) Display the current Key Version Number (KVNO) for the MSA in the Kerberos keytab.
The current KVNO is 2.
Verification steps
Verify that you have incremented the KVNO in the Kerberos keytab:
By default, the Kerberos principal for the MSA is stored in a Kerberos keytab named
<default_keytab_location>.<Active_Directory_domain>, like
/etc/krb5.keytab.production.example.com.
MSA names are limited to 20 characters or fewer. The last 4 characters are a suffix of 3 random
35
Red Hat Enterprise Linux 8 Integrating RHEL systems directly with Windows Active Directory
MSA names are limited to 20 characters or fewer. The last 4 characters are a suffix of 3 random
characters from number and upper- and lowercase ASCII ranges appended to the short host
name you provide, using a ! character as a separator. For example, a host with the short name
myhost receives an MSA with the following specifications:
Specification Value
sAMAccountName myhost!A2c$
-N, --computer-name
The short non-dotted name of the MSA that will be created in the Active Directory (AD) domain. If
you do not specify a name, the first portion of the --host-fqdn or its default is used with a random
suffix.
-O, --domain-ou=OU=<path_to_OU>
The full distinguished name of the Organizational Unit (OU) in which to create the MSA. If you do not
specify this value, the MSA is created in the default location OU=CN=Managed Service
Accounts,DC=EXAMPLE,DC=COM.
-H, --host-fqdn=host
Override the local machine’s fully qualified DNS domain name. If you do not specify this option, the
host name of the local machine is used.
-K, --host-keytab=<path_to_keytab>
The path to the host keytab to store MSA credentials. If you do not specify this value, the default
location /etc/krb5.keytab is used with the lower-cased Active Directory domain name added as a
suffix, such as /etc/krb5.keytab.domain.example.com.
--use-ldaps
Create the MSA over a Secure LDAP (LDAPS) channel.
--verbose
Print out detailed information while creating the MSA.
--show-details
Print out information about the MSA after creating it.
--show-password
Print out the MSA password after creating the MSA.
36
CHAPTER 4. ACCESSING AD WITH A MANAGED SERVICE ACCOUNT
37