LDAP & AD Authentication
CloudShark uses the Linux PAM (Pluggable Authentication Modules) authentication service to connect CloudShark to external LDAP or Active Directory network authentication services. The underlying Linux operating system can be configured in a variety of ways to support various authentication services. PAM provides a uniform interface that supports a wide variety of network architectures.
External Authentication must be enabled by a CloudShark Administrator in the Authentication section of the Administration Menu. Once enabled, CloudShark will authenticate all users against the operating system’s PAM stack.
Prerequisites
In addition to configuring PAM the default time and DNS settings of the CloudShark system may need to be reconfigured to properly integrate with an external authentication server. Please see the sections below for more information.
PAM
CloudShark uses the /etc/pam.d/rpam file for LDAP/AD authentication. This is identical to the login PAM configuration and should exist on your system as a symlink. CloudShark 3.9.5 and later creates this for you.
ln -s /etc/pam.d/login /etc/pam.d/rpam
The cloudshark user needs read permissions on the files under
/etc/pam.d controlling authentication via PAM. CloudShark by default
uses the rpam file in this directory and symlinks this to login. All
of the files referenced in the rpam file will need to have read
permissions for the cloudshark user.
NTP
Proper time synchronization is important in many external authentication setups. For AD environments the CloudShark system should be synchronized via NTP to the domain controller. This can be done by installing the NTP daemon on the CloudShark system and configuring it to point at the domain controller:
[root@cloudshark ~]# yum install ntp
Now edit the /etc/ntp.conf file and add a server entry for the domain controller:
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server myads.example.com
Now enable the NTP daemon and synchronize the system clock with the domain controller:
[root@cloudshark ~]# chkconfig ntpd on
[root@cloudshark ~]# ntpdate -u myads.example.com
DNS
For AD integration it may be helpful to add a static host entry for the domain controller to the /etc/hosts file:
10.0.0.218 myads.example.com DomainController
If the domain controller is also a DNS server, the CloudShark system should be configured to use the domain controller as its primary DNS server. This can be done by adding a static nameserver entry to the /etc/resolv.conf file pointing at the domain controller:
nameserver 10.0.0.218
In addition, the PEERDNS field for the primary network interface should be set to a value of no. Assuming eth0 is the primary network interface, the file /etc/sysconfig/network-scripts/ifcfg-eth0 should have the following line added to it:
DEVICE=eth0
HWADDR=08:00:27:64:A3:24
TYPE=Ethernet
UUID=1239052f-43ba-4e84-abf0-92ceddd08db6
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
PEERDNS=no
This field tells the system not to overwrite the /etc/resolv.conf file with a new DNS server address if one is learned via DHCP.
AD Configuration
To authenticate users against a Windows Active Directory server first you will need to install some packages using yum:
[root@cloudshark ~]# yum install sssd realmd oddjob oddjob-mkhomedir adcli /
samba-common samba-common-tools krb5-workstation openldap-clients /
policycoreutils-python
After installing the necessary packages you can join the Windows domain using the realm command:
[root@cloudshark ~]# realm join --user=Administrator adserver.example.com
By default users will have to login with their fully qualified username, for example: cloudshark@example.com. To configure this so that the domain is not required edit the file /etc/sssd/sssd.conf and change the following two lines:
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
To:
use_fully_qualified_names = False
fallback_homedir = /home/%u
Now the user in the example above can login using cloudshark as the username.
These steps were based off this guide from the LinuxTechi collection of open source Linux tutorials and guides.
Generic LDAP Configuration
LDAP Authentication can be setup using sssd. Documentation for using sssd on RHEL or Rocky Linux 8 can be found here.
First you will need to install sssd:
[root@cloudshark ~]# yum -y install sssd authconfig
SSSD does not include a default configuration file so you will have to create one manually named /etc/sssd/sssd.conf. We have created an example configuration file for an LDAP server, example.com, that requires a Bind DN of cn=Manager,dc=example,dc=com and a Bind Password of secret_password:
[sssd]
domains = LDAP
services = nss, pam
config_file_version = 2
[nss]
[pam]
[domain/LDAP]
cache_credentials = true
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://example.com
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Manager,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = secret_password
This config file must be owned by root and must be readable and writable only by the root user. Run the following two commands to ensure this:
[root@cloudshark ~]# chown root:root /etc/sssd/sssd.conf
[root@cloudshark ~]# chmod 600 /etc/sssd/sssd.conf
After this you will need to enable authentication with sssd and start the sssd service:
[root@cloudshark ~]# authconfig --update --enablesssd --enablesssdauth
[root@cloudshark ~]# chkconfig sssd on
[root@cloudshark ~]# service sssd start
Lastly run the following command to restart CloudShark:
[root@cloudshark ~]# service cloudshark restart
Now your LDAP users will be able to login and use CloudShark.
Once your users are able to login if you find that the login times are taking too long or timing out the sssd configuration may be able to be modified to lower the login time. If this is the case or if you require a more advanced LDAP configuration see our knowledge base article on Advanced LDAP.
Testing External Authentication
CloudShark utilizes the id command to determine if a user exists and which groups that user belongs to. If the id command produces the expected result for a known external user, that user should be known to CloudShark and should now be able to access the system.
[root@cloudshark ~]# id bart
uid=16777217(bart) gid=16777218(domain users) groups=16777218(domain users),16777225(cloudshark),16777217(BUILTIN\users)
The id can be timed to determine how log a login might take. To test this first delete the sssd cache files to ensure that the login information is not being cached and is being looked up on the external LDAP server. Be sure to do this step each time the id command is used:
[root@cloudshark ~]# sss_cache -E
[root@cloudshark ~]# rm -f /var/lib/sss/db/*
[root@cloudshark ~]# service sssd restart
The time command will help determine how long it will take to lookup a user and what groups they belong to. This can be used to test the performance of sssd after making any changes to the configuration file.
[root@cloudshark ~]# id bart
uid=16777217(bart) gid=16777218(domain users) groups=16777218(domain users),16777225(cloudshark),16777217(BUILTIN\users)
real 0m0.137s
user 0m0.001s
sys 0m0.003s
If this command is taking a long time to complete see our Advanced LDAP for tips on optimizing LDAP user and group lookups using a more specific search base.
TLS
LDAP servers may require TLS to authenticate a user but may not require this to look the user up using the id command. Additionally if the LDAP server is using a certificate that is not trusted by the CloudShark appliance then authenticating the user will fail. In this case the id command above will work successfully but the user will still be unable to login to CloudShark. If you are seeing these symptoms you will need to configure sssd to trust the certificate used by the server.
First copy the certificate onto your CloudShark appliance, then add the following to the /etc/sssd/sssd.conf file and restart sssd with service sssd restart:
ldap_tls_cacert = <FULL PATH TO CERT FILE>
Additional Options
Disabling SSH Access for External Users
In most setups, ssh login access should be disabled for all externally authenticated users. To restrict ssh login, edit the /etc/ssh/sshd_config file add a line defining which users should be allowed to login via ssh. For example:
AllowUsers root cloudshark
The ssh daemon should also be restarted after making this change.
[root@cloudshark ~]# service sshd restart
This will only allow the root and cloudshark users to login via ssh. More information can be found in the sshd_config manpage.
Group Creation
When CloudShark groups are created, they may reference local users, external users, or external groups. However, in order to manage an external user, CloudShark must first know about the external user. This can be done by having the user log into CloudShark, or by manually adding the user to the system as an external user. In large user deployments, it may be easier to manage CloudShark groups using external groups.
Management of Users and Groups
CloudShark only manages local users. External users must be managed using other systems. For example, it is not possible to change the password of an external user through CloudShark. It is also not possible to remove an external user from an external network group through CloudShark.
References
CentOS TipsAndTricks for WinbindADS
