SSSD Active Directory Authentication: Joining a Domain Without VPN

We have a few earlier blog posts on setting up Linux based Samba file shares with Active Directory authentication. Similarly, there are many documents on the Internet on configuring LDAP authentication to Active Directory. However, very little has been written on LDAPS authentication to Azure Active Directory Domain Services, directly over the Internet.

The approach outlined below illustrates setting up a RedHat Enterprise Linux (or clone, such as Rocky Linux, AlmaLinux, or Oracle Linux) to authenticate Azure AD users with only an LDAPS connection.  We eliminate the need for on-premises Active Directory, a VPN connection to the Azure Active Directory Domain Services servers, and even being joined to the domain. It can be an excellent way to quickly utilize Azure ADDS without a lot of overhead.

 

SSSD Active Directory Authentication

 

Prerequisites

  • An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant. 
    • [Microsoft configuration tutorial](https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance)
  • ADDS Secure LDAP certificate applied (the root must be trusted by the client)
  •  “Allow secure LDAP access over the internet” enabled in Azure Active Directory Domain Services
  • A DNS A record created in the domain's public DNS pointing to Secure LDAP external IP address
  • Remote site location WAN IP allowed in ADDS security group.
    • TCP: 636

 

 

Install SSSD

sudo yum install sssd-tools sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools

Copy the Certificate to the Server

Using the certificate applied in the Secure LDAP portion upload to the server at /etc/openldap/{certUsedWithADDS}.pem

 


 

Configure SSSD

 

All configuration of `sssd` must be done as root. So, `sudo -i` to root

 

vi /etc/sssd/sssd.conf

 

The following is a sample configuration. Please adjust variables as needed.

 

[sssd]

services = nss, pam, ssh

debug_level = 0

domains = AD #this name is arbitrary, it just needs to match the section below

 

[nss]

debug_level = 0

 

[pam]

debug_level = 0

offline_credentials_expiration = 2

offline_failed_login_attempts = 3

offline_failed_login_delay = 5

 

[ssh]

 

[domain/AD]

cache_credentials = True

enumerate = False

debug_level = 0

id_provider = ldap

auth_provider = ldap

access_provider = ldap

ldap_access_filter = memberOf=CN=All Users,OU=AADDC Users,DC={DC},DC={domainName},DC=com

ldap_schema = rfc2307bis

ldap_id_mapping = True

ldap_uri = ldaps://adds.example.com:636 #replace with DNS name of ADDS instance

ldap_search_base = OU=AADDC Users,DC={DC},DC={domainName},DC=com #Use this only for testing, user access should be tuned via group membership

ldap_id_use_start_tls = True

ldap_tls_cacert = /etc/openldap/{certUsedWithADDS}.pem

ldap_tls_cipher_suite = HIGH

ldap_default_bind_dn = CN={serviceAccountWithBindPermissions},OU=AADDC Users,DC={DC},DC={domainName},DC=com #More on this below

ldap_default_authtok_type = password

ldap_default_authtok = {serviceAccountPassword}

ldap_tls_reqcert = allow

use_fully_qualified_names = False

# Object Mappings

ldap_user_object_class = user

ldap_user_name = sAMAccountName

ldap_group_object_class = group

ldap_group_name = cn

# ID Mappings

ldap_user_objectsid = objectSid

ldap_group_objectsid = objectSid

ldap_idmap_range_size = 1048576

ldap_user_primary_group = primaryGroupID

override_homedir = /mnt/home/%u #Change this location to fit your needs

default_shell = /bin/bash

 

ldap_default_bind_dn should be the full username of the service account created. i.e. LDAPS Service Account and not the short name ldapsvc  

 

Set the permissions on the configuration file

 

chmod 600 /etc/sssd/sssd.conf

 

Restart sssd and test the configuration : 

 

systemctl restart sssd.service

id {username}

 

Confirm the user account information is returned correctly.

 


 

Next, edit /etc/sssd/sssd.conf once more and set

 

enumerate = False

 

to

 

enumerate = True

 

getent passwd  should now return all domain users from the ldap_search_base

 

Now update the allowed auth with authconfig  to permit SSH logins with domain accounts with the following command:

 

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

 

SSH authentication should now succeed with domain user accounts. 

 


 

BONUS: obfuscate bind credentials in sssd.conf 

 

Run the following command and follow prompts:

sss_obfuscate -d {domainNameInSSSDconf} #example from above: AD

 

This should auto replace ldap_default_authtok  and ldap_default_authtok_type with new values.

 


 

Troubleshooting

 

  • - Increase the debug levels in /etc/sssd/sssd.conf
    Debug Level Description
    0 Fatal Errors
    1 Critical Errors
    2 Serious Errors
    3 Mirror Errors
    4 Configuration Errors
    5 Function Information
    6 Trace Operations Messages
    7 Trace Control Messages
    8 Variable Data
    9 Most Detailed Data

 

  • Use ldapsearch to connect to Azure ADDS
  • Use id to check system user information
  • Delete cache file after changes to sssd.conf. Located at /var/lib/sss/db/cachd_domainName.ldb

 

This is an intense step-by-step guide on SSSD Active Directory authentication. If you are struggling to set up or have additional questions, please feel free to contact us!

 

Related Posts:

 

 

Subscribe Here For Our Blogs:

Recent Posts