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.


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


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


1. Some pre-requisites:
    a. 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.
    b. 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.
    c. 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.
    d. Ensure ports required by Active Directory and Kerberos are open through the network and firewalls.

2. 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.

3. Install necessary packages:
    a. SSSD: krb5-client samba-client openldap2-client sssd sssd-tools sssd-ad
    b. Winbind: krb5-client samba-client openldap2-client samba-winbind samba-winbind-32bit

4. Configure the Kerberos client to point to the Kerberos server. In most environments the AD server is the Kerberos server, that will be the assumption in our example. However, sometimes they are separated. Also, the DNS SRV records should be configured so that the Kerberos system can find the KDC. If not, under the "admin_server" parameter a "kdc" parameter would also need to be specified. Example /etc/krb5.conf:

    default_realm = EXAMPLE.COM
    clockskew = 500
    dns_lookup_realm = true
    dns_lookup_kdc = true
    forwardable = true
    default_ccache_name = FILE:/tmp/krb5cc_%{uid}
        admin_server =
    kdc = FILE:/var/log/krb5/krb5kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log
[domain_realm] = EXAMPLE.COM = EXAMPLE.COM

5. Configure the SMB protocol. You'll need to use the REALM as setup in the previous step, and you'll need to know your AD environment's workgroup. Example of global parameters in /etc/samba/smb.conf file:
    a. Winbind:

        workgroup = EXAMPLE
        kerberos method = secrets and keytab
        realm = EXAMPLE.COM
        security = ADS
        template homedir = /home/%D/%U
        template shell = /bin/bash
        winbind refresh tickets = yes
        winbind use default domain = yes
        winbind enum groups = yes
        winbind enum users = yes
        idmap uid = 10000-20000
        idmap gid = 10000-20000

    b. SSSD:

        workgroup = EXAMPLE
        kerberos method = secrets and keytab
        realm = EXAMPLE.COM
        security = ADS

6. Configure NSS. Example parameters in /etc/nsswitch.conf:
    a. Winbind:

    passwd: compat winbind
    group: compat winbind

    b. SSSD:

    passwd: compat sss
    group: compat sss

7. Configure SSSD or finish configuring Winbind (some configuration of winbind was done in the smb.conf file earlier):
    a. Winbind. Example parameters in /etc/security/pam_winbind.conf:

    cached_login = yes
    krb5_auth = yes
    krb5_ccache_type = FILE

    b. SSSD. Example /etc/sssd/sssd.conf:

    config_file_version = 2
    services = nss,pam
    domains =

    filter_users = root
    filter_groups = root


    id_provider = ad
    auth_provider = ad
    ad_domain =
    cache_credentials = true
    enumerate = false
    override_homedir = /home/%d/%u
    ldap_id_mapping = true
    ldap_referrals = false
    ldap_schema = ad

8. Configure openldap2 client (Kerberos ticket will need to be active in your session in order for ldapsearch with GSSAPI to work). Example /etc/openldap/ldap.conf for both Winbind and SSSD:

URI ldap://
BASE dc=example,dc=com

9. Establish Kerberos Connection using "kinit" with a privileged AD user (must be able to create computer accounts):

kinit Administrator

10. Create the computer account. 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

11. Configure PAM stack using pam-config:
    a. Winbind:​​​​​

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

    b. SSSD:

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

12. Enable and start your configured service:
    a. Winbind:

systemctl enable winbind
systemctl start winbind

    b. SSSD:

systemctl enable sssd
systemctl start sssd


Additional Information

Central authentication configuration is very 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 "kinit" with:

# klist

AD Server info collected by client should show after the "net ads join" with:

# net ads info

Test Kerberos authentication to AD with ("klist" must show an active ticket from "kinit"):

# 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



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:20-Oct-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact:

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