Active Directory Authentication for SAS on Linux (with realmd)

This is another post in the series about configuring a SAS platform on Linux to use Integrated Windows Authentication (IWA), in this post I’m going to jot down some notes on steps 1-7 – configuring the Linux server for Active Directory (AD) Authentication.

Some time has passed since I wrote the original post, and a few things have changed. I’m now running SAS 9.4 M3, but this post should equally apply to SAS 9.4 M2. I have also switched the Linux distribution from Debian to CentOS 7.1. I am also using a much simpler method of joining the Linux server to the AD domain, using the realmd package (previously there were lots of individual steps using the underlying packages but realmd automates most of this). In this post I’m going to outline the simpler method using realmd of course.

Here goes …

This is a small development installation and the SAS metadata server, SAS compute tier, and SAS mid-tier are all running on the same Linux server machine named sas94m3 (with a fully qualified name of It is going to join an AD domain CORP.EXAMPLE.COM using the domain controller

Kerberos Client Config

I first install the Kerberos client software, configure it to use AD, and use kinit to get a ticket-granting ticket (TGT) as a domain admin. That way I don’t have to provide any credentials when using realmd.

yum install krb5-workstation krb5-devel
vi /etc/krb5.conf

NOTE: The krb5-devel package provides a /usr/lib64/ -> symlink. I noticed that SAS looks for after turning on debugging in the sasauth.conf file.

The following Kerberos config was used (/etc/krb5.conf). There were a few minor edits to the default template originally installed (changes shown in bold below):

 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = CORP.EXAMPLE.COM
 default_ccache_name = KEYRING:persistent:%{uid}
   kdc =
   admin_server =

Get a Kerberos TGT for a domain admin:

kinit -V Administrator
Using default cache: persistent:0:0
Using principal: Administrator@CORP.EXAMPLE.COM
Password for Administrator@CORP.EXAMPLE.COM: ****************
Authenticated to Kerberos v5

Joining the Domain using realmd

It’s a good idea to make sure that DNS is working on the Linux server, checking the domain is discoverable, by making sure the following SRV record resolves for the domain:

dig -t SRV

Next install the realmd package:

yum install realmd

I then create a custom config file for realmd prior to joining the domain. This is because I want to replicate previous behaviour where home dirs were in /home/userid and bare unqualified userids were used to login. You don’t need to create this file if you want to go with the default of /home/ for the home directory and using qualified userids (e.g. CORP\\userid or

vi /etc/realmd.conf

This is my /etc/realmd.conf file contents:

default-home = /home/%U
default-shell = /bin/bash

fully-qualified-names = no

The next step is to discover the domain and find out what additional packages might be needed:

realm discover --verbose CORP.EXAMPLE.COM
 * Resolving:
 * Performing LDAP DSE lookup on:
 * Successfully discovered:
  type: kerberos
  realm-name: CORP.EXAMPLE.COM
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common

Then make sure all the required packages listed are installed:

yum install oddjob oddjob-mkhomedir sssd adcli samba-common

Now we can join the domain (I like to use the –verbose option to see what’s going on):

realm join --verbose CORP.EXAMPLE.COM
 * Resolving:
 * Performing LDAP DSE lookup on:
 * Successfully discovered:
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
 * LANG=C /usr/sbin/adcli join --verbose --domain --domain-realm CORP.EXAMPLE.COM --domain-controller --login-type user --login-ccache=/var/cache/realmd/realm-ad-kerberos-2X4E2X
 * Using domain name:
 * Calculated computer account name from fqdn: SAS94M3
 * Using domain realm:
 * Sending netlogon pings to domain controller: cldap://
 * Received NetLogon info from:
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-1GcMKP/krb5.d/adcli-krb5-conf-hG6H4k
 * Looked up short domain name: CORP
 * Using fully qualified name:
 * Using domain name:
 * Using computer account name: SAS94M3
 * Using domain realm:
 * Calculated computer account name from fqdn: SAS94M3
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Using fully qualified name:
 * Using domain name:
 * Using computer account name: SAS94M3
 * Using domain realm:
 * Looked up short domain name: CORP
 * Computer account for SAS94M3$ does not exist
 * Found well known computer container at: CN=Computers,DC=corp,DC=example,DC=com
 * Calculated computer account: CN=SAS94M3,CN=Computers,DC=corp,DC=example,DC=com
 * Created computer account: CN=SAS94M3,CN=Computers,DC=corp,DC=example,DC=com
 * Set computer password
 * Retrieved kvno '2' for computer account in directory: CN=SAS94M3,CN=Computers,DC=corp,DC=example,DC=com
 * Modifying computer account: dNSHostName
 * Modifying computer account: userAccountControl
 * Modifying computer account: operatingSystem, operatingSystemVersion, operatingSystemServicePack
 * Modifying computer account: userPrincipalName
 * Discovered which keytab salt to use
 * Added the entries to the keytab: SAS94M3$@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/SAS94M3@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: HOST/ FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/SAS94M3@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/ FILE:/etc/krb5.keytab
 * /usr/bin/systemctl enable sssd.service
ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/'
 * /usr/bin/systemctl restart sssd.service
 * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
getsebool:  SELinux is disabled
ln -s '/usr/lib/systemd/system/oddjobd.service' '/etc/systemd/system/'
 * Successfully enrolled machine in realm

The next step is to permit logins. I’ve allowed all AD logins, but you might want to be more specific.

realm --verbose permit --realm --all
 * /usr/bin/systemctl restart sssd.service
 * Successfully changed permitted logins for realm


Now the server has joined the domain you can do a few simple tests to see if it is working.

Try to look up a domain user:

getent passwd sasdemo
sasdemo:*:1323801154:1323800513:SAS Demo User:/home/sasdemo:/bin/bash

If you didn’t use fully-qualified-names=no in /etc/realmd.conf you will need to use a qualified userid like so:

getent passwd CORP\\sasdemo
getent passwd

If the look up works, you can try logging in as a domain user:

su - sasdemo

If this works then you should be able to authenticate to the SAS Metadata Server using a domain account and launch a SAS Workspace Server. You won’t be able to use Integrated Windows Authentication yet because that requires some more configuration to be done – a topic for a future blog post :)

Finally, a few other things you might find useful ….

Rejoining the Domain

I you edit the realmd config /etc/realmd.conf you will want to leave and rejoin the domain for the settings to take effect:

realm leave --verbose CORP.EXAMPLE.COM
 * Removing entries from keytab for realm
 * /usr/sbin/sss_cache --users --groups --netgroups --services --autofs-maps
 * Removing domain configuration from sssd.conf
 * /usr/sbin/authconfig --update --disablesssdauth --nostart
getsebool:  SELinux is disabled
 * /usr/bin/systemctl disable sssd.service
rm '/etc/systemd/system/'
 * /usr/bin/systemctl stop sssd.service
 * Successfully unenrolled machine from realm
realm join  --verbose CORP.EXAMPLE.COM

Leaving the Domain and Removing the Packages

If you need to want to start from scratch, or revert back to non-AD host authentication, you can leave the domain and uninstall the packages like so:

# Leave the domain
realm leave CORP.EXAMPLE.COM
# Remove the packages installed (and then any automatically installed dependances no longer needed)
yum remove oddjob oddjob-mkhomedir sssd adcli realmd krb5-workstation sssd
yum autoremove
# Remove the remaining SSSD config (if you don't need it anymore)
rm /etc/sssd/sssd.conf
# Remove the server's keytab (if you don't need it anymore)
rm /etc/krb5.keytab

Finally go into AD Active Directory Users and Computers and remove the computer account for the server (SAS94M3).

Your Turn

If you’ve found this useful, or have any additional comments or tips on getting a Linux server authenticating against Active Directory in preparation for a SAS platform install, please let me know by leaving a comment below.

9 thoughts on “Active Directory Authentication for SAS on Linux (with realmd)”

  1. Hi Paul

    This now sounds like you can do it before breakfast;-), many thanks for sharing this.

  2. Thanks Bruno. I found it certainly does make it much easier, automating some of the otherwise manual tasks, and reducing the chances of human error.

  3. Hi Paul, I tried this configuration and it worked perfectly, but, only users in the windows domain configured are able to sign, how can be this functionality extended to windows domains with a trusted relationship with the configured domain?

  4. Rafael, I’m doing some more testing using realmd (sssd) and multiple domains and I’ll post my findings later on. My test environment has 3 domains (2 domains within the same forest and another domain in a separate trusted forest). How is yours configured: 2 domains within the same forest or 2 domains in separate trusted forests?

  5. Rafael, I have it working with multiple domains in the same forest. If DOMAIN1.EXAMPLE.COM is my first domain, I needed to manually add the second domain DOMAIN2.EXAMPLE.COM into /etc/krb5.conf (otherwise I was getting authentication failures for DOMAIN2 users and the following error in /var/log/messages sssd_be: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot find KDC for realm “DOMAIN2.EXAMPLE.COM”).

    The relevant sections of my /etc/krb5.conf look like this:
    kdc =
    admin_server =
    kdc =
    admin_server =

    After this DOMAIN1 users could log in using the unqualified user id (e.g. user1) and the unqualified user id would be used in the Accounts tab of the user in SAS Management Console User Manager plug-in.

    DOMAIN2 users would have to log in with the qualified user id (e.g. user2@DOMAIN2) and that qualified user id would have to be used in the Accounts tab of the user in SAS Management Console User Manager plug-in.

    You might change this behaviour with the sssd.conf use_fully_qualified_names option but I have not tried this myself as yet.

  6. I should have also mentioned that I was unable to get cross-forest working with sssd. As far as I can see it is not support as yet. The man page for sssd-ad says:

    “The AD provider is able to provide identity information and authentication for entities from
    trusted domains as well. Currently only trusted domains in the same forest are recognized.”

    If you have a cross-forest environment then you might want to look into alternative methods like FreeIPA, Centrify etc.

  7. Hi Paul.

    Thanks for you reply!!

    This information is very useful for me, I had problems with the 2nd domain, now, I know how to solve it.

    Also, we want to authenticate users from a third domain, but this is in another forest with a trust relationship.

    As I can read, this is not supported by sssd.

    Thanks again for you reply!

    Appreciate your help!


  8. Hi Paul.
    Correctly, I understand that if the SAS configuration is divided into meta tier, middle tier and computer tier each on its own Linux server, then do you need to perform these settings on each separate server?

  9. It depends on your architecture and what you are trying to achieve. For AD authentication for the SAS Metadata Server then, yes, on it’s machine. For the compute tier if you want the SAS Object Spawner to launch SAS Workspace Server instances using the credentials of the requesting user then, yes, you will need to do it on that machine too. Alternatively, if you are doing SAS Token Authentication for SAS Workspace Servers, so they launch using a shared identity then, no, it won’t be necessary on that machine. For the mid-tier machine, you won’t be launching processes as the requesting user, so it won’t be necessary to do user level AD authentication on that machine. However, if you want to do IWA web authentication then you will need to do some Kerberos configuration on that machine to support it.

    You may want to consider getting some help from SAS Professional Services or a local SAS Partner if you want more detailed assessment and advice for your specific environment. That will increase the likelihood of success and reduce the time to implementation.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.