Authenticating other services against AD

From SambaWiki
(Redirected from Samba4/beyond)
Jump to: navigation, search

Contents

Introduction

You have now finished setting up your new/migrated samba4 domain and now have the job of hooking up several other services to Active Directory or LDAP. Below you will find a number of configuration examples.

Please keep in mind, that some of the examples may only work on specific platforms and/or distributions and may have to be adapted.

If you manage to authenticate services not shown here, could you please post (to the samba list) instructions, or a link to instructions, of how you got your service to authenticate to Samba AD.

Apache

Authenticating against Active Directory

Example of where you need this: You want Apache to permit access to a directory on your webserver just for AD users that are members of a defined AD group (I used group "test" in the example). Username and password should be validated against AD.


1. Create a new user in ADUC or with samba-tool, that Apache will use for connecting to the AD (I used "apache-connect" in the example below).


2. Add the following to your .htaccess or your httpd.conf (vHost/directory/... directive):

AuthName "AD authentication"
AuthBasicProvider ldap
AuthType Basic
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN On
AuthLDAPURL ldap://{AD-Hostname/IP}:389/cn=Users,dc={your Domain DN}?sAMAccountName?sub?(objectClass=*)
AuthLDAPBindDN cn=apache-connect,cn=Users,{your Domain DN}
AuthLDAPBindPassword {password}
require ldap-group cn=test,cn=Users,{your Domain DN}

With this configuration, the username is searched for just in the "Users" container and below. If you want to search in any OU of your domain, then you have to add

REFERRALS off

to your "/etc/openldap/ldap.conf". Otherwise accessing doesn't work and apache will log "auth_ldap authenticate: user xxx authentication failed; URI / [ldap_search_ext_s() for user failed][Operations error]!". If you're still getting this error after turning referrals off, set Apache to connect to Samba/AD port 3268 (AD global catalog) instead to the standard LDAP 389 port.


3. Make sure that your configuration file is only readable by the webserver, because of the password!


4. Restart apache.

Apache Single Sign-On

This section shows you how to authenticate a login to an apache hosted website on your intranet without having to type your password in. The Kerberos authentication used with AD will pass from your desktop domain login and therefore avoid the need to challenge again for credentials (so called Single Sign On). It will however drop back to a simple password challenge if suitable Kerberos credentials are missing.

For this to all work we require a correctly configured krb5.conf and a working DNS setup for your AD domain. The webserver machine used may or may not be joined to AD, it shouldn't matter.

The krb5.conf file should be copied from the sample one generated on Samba AD provisioning (and should be the /etc/krb5.conf on the DC if you have setup things properly) to /etc/krb5.conf on the webserver. Obviously if hosting the webserver on your Samba DC there should be nothing to do.

On DNS, we require a working forward and reverse DNS for the webserver. The DNS provisioned during the setup only comes out of the box with a working forward zone (and only a forward entry for the DC, so you will need a forward entry added for your webserver, too if not using your DC as a webserver).

To add a reverse zone use (with the subnet my webserver is on being 192.168.1.0/24):

# samba-tool dns zonecreate ADC 1.168.192.in-addr.arpa

where "ADC" is the name of the Active Directory domain controller.

Then you can add a reverse record for your webserver.

# samba-tool dns add s4dc 1.168.192.in-addr.arpa 150 PTR servername.domainname

where "servername" is the name of this webserver that has an IP of 192.168.1.150. "domainname" is your domain's DNS domain name, usually the realm name lower case.

We next need to setup an SPN (Service Principal Names) for the server name that any website resolves to (so the actual server name that a CNAME points to, fully qualified). If not using virtual hosting the web address and the machine name will be the same. So:

# samba-tool user create --random-password http-servername
# samba-tool spn add HTTP/servername.domainname http-servername
# samba-tool domain exportkeytab /root/httpd.keytab --principal=HTTP/servername.domainname@YOUR_REALM_NAME.TLD

where "servername" is the name of this webserver, including the one in "http-servername". "YOUR_REALM_NAME.TLD" should be replaced by your AD realm name.

Transfer this /root/httpd.key tabfile to your webserving machine and place in /etc/httpd/conf/httpd.keytab. Then chown and chmod this file so apache can read but not alter it i.e

# chown root:apache /etc/httpd/conf/httpd.keytab
# chmod 640 /etc/httpd/conf/httpd.keytab

Then add to your Apache configuration something like:

<location "/login.html">
       AuthType Kerberos
       AuthName "Network Login"
       KrbMethodNegotiate On
       KrbMethodK5Passwd On
       KrbAuthRealms YOUR_REALM_NAME.TLD
       require valid-user
       Krb5KeyTab /etc/httpd/conf/httpd.keytab
       KrbLocalUserMapping On
</Location>

Again replace YOUR_REALM_NAME.TLD with the AD realm name.

This is securing the "login.html" page so as the user accessing it, it must have a domain login.

On the client side, for Single Sign On to work there is a little configuration required. Windows IE is already configured to pass Kerberos credentials with Intranet (non-fully qualified) addresses.

On Firefox, on all platforms, enter "about:config" in the address bar. Search for "negotiate"

Add your site or sites to "network.negotiate-auth.trusted-uris" e.g. "http://servername, http://servername.domainname". You can just use http:// and it will pass your credentials to any site that asks for them (not recommended even though they are encrypted). Ensure "network.negotiate-auth.using-native-gsslib" is set to true (default).

On Chrome/Chromium, launch with:

  1. google-chrome --auth-server-whitelist="servername,servername.domainname" --auth-negotiate-delegate-whitelist="servername,servername.domainname"

Again these parameters take "*", but again will pass your credentials to any site that asks for them. But more subtile wildcarding is possible, to make this more convenient for many sites.

(Windows seems to not require this for Chrome)

So then using any of these browsers accessing the url (in this case) of http://servername/login.html should take you there without prompting for a password, if on a AD joined computer and logged in using a domain user.

If you use a non-joined computer you should get prompted for your login and password. Providing a domain user login should let you in to the site.

(This tutorial was provided by Colin Simpson. Thanks.)

Secure passwordless SSH

This section explains how to allow passwordless SSH between Samba AD joined Linux hosts (or Passwordless SSH using Putty from Windows machines joined to the same domain).

This section assumes your joined machine's krb5.conf files are appropriately configured (usually this happens automatically when they are joined) and are set to point to a suitable krb5 keytab. This is generated by running "net ads keytab create" (on the joined machine), which will usually put this in a suitable place for kerberos to find, by default /etc/krb5.keytab. If not, you may need to add "default_keytab_name" entry in you krb5.conf to point to the generated /etc/krb5.keytab.

Also on DNS, we require working forward and reverse entries for the SSH servers. See the Apache Single Sign-On section for how to achieve this.

In /etc/ssh/sshd_config ensure you have the following options set:

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIKeyExchange yes                # If your version supports this
GSSAPIStoreCredentialsOnRekey yes    # If your version supports this

Then restart the sshd.

For the client side, ensure you have the following set under an appropriate "Host" section in /etc/ssh/ssh_config:

Host *
       GSSAPIAuthentication yes
       GSSAPIDelegateCredentials yes
       GSSAPIKeyExchange yes         # If your version supports this
       GSSAPIRenewalForcesRekey yes  # If your version supports this
       GSSAPITrustDns yes

The options marked "If your version supports this" are provided in many distribution shipped versions of OpenSSH. The "KeyExchange" options allow host verification via GSSAPI. The "GSSAPIStoreCredentialsOnRekey" (server option) and "GSSAPIRenewalForcesRekey" (client options) allow a Kerberos renewal to propagate down existing SSH connections.

I have also required in smb.conf:

kerberos method = secrets and keytab

and in /etc/security/pam_winbind.conf :

krb5_auth = yes
krb5_ccache_type = FILE

for the console based logins and SSH failback to password to generate a Kerberos TGT ticket (as in if the passwordless login fails due to not having a suitable ticket on the calling machine). This is essential if using things like NFSv4 with Kerberos Authentication.

To also allow Putty SSH logins to be passwordless from a Windows machine joined to the same domain as your Linux host requires a reasonably up-to-date version of Putty. Then all that needs set for a particular session are: under the Connection -> SSH -> Auth -> GSSAPI, select "Attempt GSSAPI authentication (SSH-2 only)" and "Allow GSSAPI credential delegation". And maybe under Connection -> Data , select "Use system username" if desired.

It is desirable to set "Trust this computer for delegation to any service (Kerberos only)" under the "Delegation" tab in Users and Computers for the computer objects you are SSHing into. This allows your kerberos tickets to pass to the machine you are SSHing into. Through this you can use Kerberized services on the system you have SSH'd into, for example SSHing into yet another computer without a password.

(This tutorial was provided by Colin Simpson. Thanks.)

openLDAP proxy to AD

Example of where you need this: If you don't want to have a DC with all its services and open ports in your DMZ, you can setup a back-ldap proxy with openLDAP. Then you can limit the access to your DC to just this one host and the LDAP port 389, and all services on other hosts in your DMZ can access the AD using the proxy.


1. Use the following slapd.conf example:

### Schema includes ###########################################################
include                 /etc/openldap/schema/core.schema
include                 /etc/openldap/schema/cosine.schema
include                 /etc/openldap/schema/inetorgperson.schema
include                 /etc/openldap/schema/misc.schema
include                 /etc/openldap/schema/nis.schema


## Module paths ##############################################################
modulepath              /usr/lib64/openldap/
moduleload              back_ldap
moduleload              rwm


# Main settings ###############################################################
pidfile                 /var/run/openldap/slapd.pid
argsfile                /var/run/openldap/slapd.args


### Database definition (Proxy to AD) #########################################
database                ldap
readonly                yes
protocol-version        3
rebind-as-user
uri                     "ldap://{AD-Hostname/IP}:389"
suffix                  "{your Domain DN}"
overlay                 rwm
rwm-map                 attribute       uid     sAMAccountName
rwm-map                 attribute       mail    proxyAddresses


### Logging ###################################################################
loglevel                0

If you already have an openLDAP server with a local database running, you can add the proxy part anyway, if your AD resides in a different branch.


2. If you don't need remappings of attributes (like mapping "sAMAccountName" to "uid" and "proxyAddresses" to "mail" in the example above), you can skip this parameters.


3. If you use remappings, you might get errors when using ldap/slap commands like (for the above two remappings):

 /etc/openldap/slapd.conf: line 28: warning, destination attributeType 'sAMAccountName' is not defined in schema
 PROXIED attributeDescription "SAMACCOUNTNAME" inserted.
 /etc/openldap/slapd.conf: line 29: warning, destination attributeType 'proxyAddresses' is not defined in schema
 PROXIED attributeDescription "PROXYADDRESSES" inserted.

This happens, if you remap attributes, that you had not defined in the schemas you had included. Search the web to get the valid schema entries, add them to a file and include it in slapd.conf. For the above two remappings, the following would be in the schema file, to let the two errors dissappear:

attributetype ( 1.2.840.113556.1.4.221
       NAME 'sAMAccountName'
       SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
       SINGLE-VALUE )
 
 attributetype ( 1.2.840.113556.1.2.210
       NAME 'proxyAddresses'
       SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )


4. Restart the openLDAP service.

Nslcd: User/Groups from AD through openLDAP proxy

Example of where you need this: You need to resolve user/groups from AD through an openLDAP proxy, because you want to see the usernames/groups instead of UIDs/GIDs. Or you need to provide authentication to AD through the openLDAP proxy.


1. This requires that you have successfully configured an openLDAP proxy to AD.


1. Create a new user in ADUC or with samba-tool, that nslcd will use for connecting to the AD (I'd used "nslcd-connect" in the example below).


2. Adapt the following "/etc/nlscd.conf" example to your environment:

# Mappings for Active Directory
pagesize 1000
referrals off

# Passwd
filter passwd (&(objectClass=posixAccount)(!(objectClass=computer))(uidNumber=*))
map    passwd homeDirectory     UnixHomeDirectory
map    passwd gecos             displayName
map    passwd gidNumber         primaryGroupID

# Shadow
filter shadow (&(objectClass=posixAccount)(!(objectClass=computer))(uidNumber=*))
map    shadow shadowLastChange  pwdLastSet

# Groups
filter group (&(objectClass=posixGroup)(gidNumber=*))
map    group uniqueMember       member
 
# Local account for nsclcd
uid nslcd
gid ldap

# Where is the LDAP
uri ldap://{openLDAP-Proxy-Hostname/IP}:389
base cn=Users,{your Domain DN}

# Connect-Account
binddn cn=nslcd-connect,cn=Users,{your Domain DN}
bindpw {password}

This example assumes, that you've mapped the attribute "sAMAccountName" to "uid", like in the example of openLDAP proxy to AD above. Otherwise you have to map the attribute here. Also it is required, that the user accounts have an uidNumber and the groups a gidNumber attribute.


3. Start the nslcd service.

Authentication against AD

Example of where you need this: You want to authenticate users against AD.


1. This requires that you have successfully configured Nslcd with to AD to get the user information to the system..


2. Edit your "/etc/pam_ldap.conf" the following way:

base {your Domain DN}
binddn cn=nslcd-connect,cn=Users,{your Domain DN}
bindpw {password}
bind_policy soft
pam_login_attribute sAMAccountName
uri ldap://{openLDAP-Proxy-Hostname/IP}:389/
ssl no

Authentication against AD through openLDAP proxy

Example of where you need this: You want to authenticate users through an openLDAP proxy against AD.


1. This requires that you have successfully configured Nslcd that uses an openLDAP proxy to AD to get the user information to the system..


2. Edit your "/etc/pam_ldap.conf" the following way:

base {your Domain DN}
binddn cn=nslcd-connect,cn=Users,{your Domain DN}
bindpw {password}
bind_policy soft
uri ldap://{openLDAP-Proxy-Hostname/IP}:389/
ssl no
Personal tools
Namespaces

Variants
Actions
Navigation
Tools