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.
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.
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
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:
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.
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
[root@cloudshark ~]# realm join --user=Administrator adserver.example.com
By default users will have to login with their fully qualified username, for
firstname.lastname@example.org. 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
use_fully_qualified_names = False fallback_homedir = /home/%u
Now the user in the example above can login using
cloudshark as the username.
Generic LDAP Configuration
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
[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)
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
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.
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
ldap_tls_cacert = <FULL PATH TO CERT FILE>
cloudshark user needs read permissions on the files under
controlling authentication via PAM. CloudShark by default uses the
in this directory and symlinks this to
login. All of the files referenced in
rpam file will need to have read permissions for the
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
cloudshark users to login via ssh. More
information can be found in the sshd_config manpage.
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.