Manually Join AD in SUMA 5 Container

SUSE Manager Server 5.0 Container

Manual configuration of AD in SUMA Container.

Some Pre-requisites:

1. Configure NTP to use the same configuration as the AD Server environment. Many errors authenticating come down to the client not able to communicate with the AD server due to time differences.
2. The server should either be using the AD servers as its DNS nameservers, or the same DNS servers as the AD server is using for its nameservers. Not having this configured, along with missing any required AD DNS records, can result in issues with the client finding and using the AD server.
3. Ensure ports required by Active Directory and Kerberos are open through the network and firewalls.
4. Determine how many SUMA containers will be connected to AD. If there will be more than one, a naming scheme will be needed for the computer account of the container. Otherwise the default container hostname of uyuni-server.mgr.internal will be used.
5. Note that Winbind is not available and SSSD will need to be used.
6. The SUMA container must be deployed and running.

Enter the Container

1. Future steps, except Web UI and Optional steps stated otherwise, will be performed within the container:

   # mgrctl term

Make Configuration Changes

1. Configure the Kerberos client within the container by creating a /etc/rhn/krb5.conf.d/krb5.conf file:

   In AD all domain controllers by default are the KDC and DNS server as well. After configuring the default realm it can rely on AD SRV DNS records to find the kdc settings, if 'dns_lookup_kdc = true'. If using DNS is not wanted, or to force specific domain controllers, then set dns_lookup_kdc to false and uncomment the entries under [realms].
   Example krb5.conf file configuration:

   [libdefaults]
       default_realm = EXAMPLE.COM
       dns_lookup_kdc = true
       forwardable = true
       default_ccache_name = FILE:/tmp/krb5cc_%{uid}
   [realms]
       EXAMPLE.COM = {
           admin_server = example.com
           #kdc = dc1.example.com
           #kdc = dc2.example.com
       }
   [logging]
       kdc = FILE:/var/log/krb5/krb5kdc.log
       admin_server = FILE:/var/log/krb5/kadmind.log
       default = SYSLOG:NOTICE:DAEMON
   [domain_realm]
       .example.com = EXAMPLE.COM
       example.com = EXAMPLE.COM

2. Configure SSSD within the container:
   

   Example configuration of file /etc/sssd/sssd.conf

   [sssd]
   config_file_version = 2
   services = nss,pam
   domains = example.com
   
   [nss]
   filter_users = root
   filter_groups = root
   
   [pam]
   
   [domain/example.com]
   id_provider = ad
   auth_provider = ad
   ad_domain = example.com
   #
   ## Per pre-requisites, if more than one SUMA container will be joined to AD,
   ## uncomment the below parameter and use your unique naming scheme for this container here: 
   # ad_hostname = examplesuma1
   ## That will make a name of examplesuma1.example com combining the unique ad_hostname with the ad_domain value. 
   ## "-H examplesuma1.example.com" will need to be added to the adcli join command in a later step.
   #
   cache_credentials = true
   enumerate = false
   override_homedir = /home/%d/%u
   ldap_id_mapping = true
   ldap_referrals = false
   ldap_schema = ad
   krb5_keytab = /etc/rhn/krb5.conf.d/krb5.keytab
   

Join Domain and Restart SSSD

1. 1. Create the computer account and join to the domain (AD user must be able to create computer accounts) within the container:
      To reflect a unique name, other than uyuni-server.mgr.internal, "-H examplesuma1.example.com" will need to be added. It gives a unique name of "examplesuma1.example.com" to this container. It will need a matching sssd.conf configuration. Replace it with your unique naming scheme for this container. If you don't plan on joining more than one SUMA server to AD you can simply run the command below.

      uyuni-server:/ # adcli join -D example.com

2. Restart the SSSD daemon:

   uyuni-server:/ # systemctl restart sssd
   

3. Exit container
   

   uyuni-server:/ # exit

SUMA WebUI 

1. 1. In the SUSE Manager Web UI, navigate to Users -> Create User

   2. Create the user with (a) the naming format matching what is accepted by AD and (b) check the Pluggable Authentication Modules (PAM) checkbox for the user.

Common Optional Step: Configure LDAP/KRB5 Client Toolbox (outside of container on SLE Micro)

1. Configure and deploy toolbox:

   # mv .toolboxrc{,.bak}
   # echo "TOOLBOX_NAME=openldap2-client" >.toolboxrc
   # echo "REGISTRY=registry.opensuse.org" >> .toolboxrc
   # echo "IMAGE=opensuse/leap:latest" >> .toolboxrc
   # toolbox
   

2. In toolbox shell, (if the shell was exited, it can be re-entered with the "toolbox enter openldap2-client" command.) install openldap2-client and krb5-client:

   openldap2-client:/ # zypper in openldap2-client cyrus-sasl-gssapi krb5-client

3. In toolbox shell, configure /etc/openldap/ldap.conf:

   URI ldap://example.com
   BASE dc=example,dc=com
   REFERRALS OFF

4. Exit toolbox shell
   

   openldap2-client:/ # exit

5. Copy krb5.conf and krb5.keytab into toolbox, then enter to use:
   

   # podman cp 'uyuni-server':/etc/rhn/krb5.conf.d/krb5.conf 'openldap2-client':/etc/krb5.conf
   # podman cp 'uyuni-server':/etc/rhn/krb5.conf.d/krb5.keytab 'openldap2-client':/etc/krb5.keytab
   # toolbox enter openldap2-client

    

Central authentication configuration is environment dependent. Administrators are advised to carefully look over the parameters given as examples and to use the man pages to search for any additional parameters needed, if any.

After completing all the steps in this document the following tests can be run. Some of these will need to be run in the toolbox specified in "Common Optional Step: Configure LDAP/KRB5 Client Toolbox" section of this TID:

Kerberos ticket information can be tested in the toolbox with:

openldap2-client:~ # klist -k -t /etc/krb5.keytab

Test Kerberos authentication to AD, and search LDAP, in toolbox with ("klist" must show an active ticket from successful "kinit". Also, "Optional Step: Configure LDAP Client" must be completed):

openldap2-client:~ # ldapsearch -Y GSSAPI cn=Administrator

AD Server info collected by client should show after successfully joining the computer account in the SUMA container.

# mgrctl term
uyuni-server:/ # adcli info example.com

A different user known to be in the AD database can be used instead of Administrator.

NSS access through SSSD:

uyuni-server:/ # id Administrator
uyuni-server:/ # getent passwd Administrator

After validating above NSS is working, test PAM stack without password, as root, using:

uyuni-server:/ # su - Administrator

Lastly, validate with password as well (sshd and pam-config changes will not be persistent in container):

uyuni-server:/ # systemctl start sshd
uyuni-server:/ # pam-config -a --sss
uyuni-server:/ # ssh Administrator@localhost