Manually join AD on SUSE Linux Enterprise Server 12 or 15 without Yast usage

This document (7018461) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15 SP3
SUSE Linux Enterprise Server 15 SP2
SUSE Linux Enterprise Server 15 SP1
SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server 12 SP4
SUSE Linux Enterprise Server 12 SP3
SUSE Linux Enterprise Server 12 SP2
SUSE Linux Enterprise Server 12 SP1
SUSE Linux Enterprise Server 12

Situation

Configuration via command line without usage of Yast2.
This is useful for automation purposes.

Resolution

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. Either configure NSCD not to cache what Winbind or SSSD is caching (e.g. users and groups) or stop and disable NSCD all together. Having multiple caches for the same things can cause strange conflicts and issues.
  3. 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.
  4. Ensure ports required by Active Directory and Kerberos are open through the network and firewalls.
  5. Configure the system FQDN. The command “hostname -f” should return the FQDN.
  6. Look over the costs and benefits of SSSD vs Winbind and select the best service for your environment. You'll need to know which one you are using for the rest of these steps.
    1. Keep in mind that if you choose SSSD, but also want to run a samba file server, then running winbindd is mandatory since samba 4.8. In that situation, when a user establishes an SMB session, SSSD provides the NSS information and smbd delegates the user authentication to Winbind. Additionally, it requires careful setup because both services will attempt to renew the computer account password at regular intervals which can end in one daemon or another not able to login. This configuration is not covered in this document.

Common Steps

  1. Install necessary packages:

    # zypper in krb5-client
    
  2. Configure the Kerberos client

    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 /etc/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
    

Option 1: Join Using Winbind

  1. Install necessary packages:

    # zypper in samba-client samba-libs samba-winbind
    
  2. Configure smb.conf:

    You'll need to use the REALM as setup in the previous step and you'll need to know your domain's netbios name for the workgroup parameter.

    It is important to select the appropriate idmap backend for your needs and to set the ranges properly. See the following TID for options and examples: https://www.suse.com/support/kb/doc/?id=000017458

    Example of global parameters in /etc/samba/smb.conf file:

    [global]
        workgroup = EXAMPLE
        kerberos method = secrets and keytab
        realm = EXAMPLE.COM
        security = ADS
    
        winbind refresh tickets = yes
        winbind use default domain = yes
        template shell = /bin/bash
        template homedir = /home/%D/%U
    
        idmap config * : backend = tdb
        idmap config * : range = 10000-19999
        idmap config EXAMPLE : backend = rid
        idmap config EXAMPLE : range = 20000-29999
    
  3. Configure NSS:

    Example parameters in /etc/nsswitch.conf:

    passwd: compat winbind
    group: compat winbind
    
  4. Establish Kerberos Connection:

    Use "kinit" with a privileged AD user (must be able to create computer accounts):

    # kinit Administrator
    
  5. Create the computer account and join the domain:

    The "-k" flag uses the Kerberos ticket created in the previous step for authentication. Alternatively one could use the "-U" flag with the administrative user and password.

    # net ads join -k
    
  6. Enable and start the Winbindd daemon:

    # systemctl enable winbind
    # systemctl start winbind
    
  7. Configure PAM:

    Example configuration for /etc/security/pam_winbind.conf:

    [global]
    krb5_auth = yes
    krb5_ccache_type = FILE
    

    Enable using pam-config:

    # pam-config -a --winbind
    # pam-config -a --mkhomedir
    

Option 2: Join Using SSSD

  1. Install the required packages:

    # zypper in adcli sssd sssd-ldap sssd-ad sssd-tools
    
  2. Configure sssd.conf:

    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
    cache_credentials = true
    enumerate = false
    override_homedir = /home/%d/%u
    ldap_id_mapping = true
    ldap_referrals = false
    ldap_schema = ad
    
  3. Configure NSS:

    Example parameters in /etc/nsswitch.conf:

    passwd: compat sss
    group: compat sss
    
  4. Create the computer account and join to the domain (AD user must be able to create computer accounts):

    # adcli join -D example.com
    Password for [Administrator@](<mailto:Administrator@EXAMPLE.COM>)EXAMPLE.COM:
    
  5. Enable and start the SSSD daemon:

    # systemctl enable sssd
    # systemctl start sssd
    
  6. Configure PAM:

    Enable using pam-config:

    # pam-config -a --sss
    # pam-config -a --mkhomedir
    

Common Optional Step: Configure LDAP Client

  1. Install required packages:

    # zypper in openldap2-client cyrus-sasl-gssapi
    
  2. Configure /etc/openldap/ldap.conf:

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

Additional Information

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.

Useful commands for testing listed below:

Kerberos ticket information should list after successful "kinit" with:

# klist

AD Server info collected by client should show after successfully joining the computer account.
Winbind:

# net ads info

SSSD:

# adcli info example.com

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

# ldapsearch -Y GSSAPI cn=Administrator

After completing all the steps in this document the following tests can be run. A different user known to be in the AD database can be used instead of Administrator.

NSS access through SSSD or Winbind:

# id Administrator
# getent passwd Administrator

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

# su - Administrator

Lastly, validate with password as well:

# ssh Administrator@localhost

 

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7018461
  • Creation Date: 09-Jan-2017
  • Modified Date:18-Feb-2022
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center