SHIFT

--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools


Sidebar

Recently Changed Pages:

View All Pages


View All Tags


LinkedIn




WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.


Pages with comments

View All Comments

solarisadauth

AD LDAP Authentication for Solaris

This manual goes on after installing AD Identity Management for Unix. Of course you'll also need Active Directory 2008 R2 Basic Installation and Install Solaris 10 Update 8.
If you've managed to install all requirements listed in these articles you can do a quick test to see whether the LDAP works and if the bind user can get a connection. But first you'll need a AD user which is enabled for Unix authentication. After all, that's what we installed the Identity Management for Unix for.

Note: Through testing I found out that for Solaris to authenticate on AD the bind user must be member of the domain users group, not the domain guests. If the bind user is member of domain guests this error will be displayed (specific error is dependent on usage of ldapbind command):
ldap_simple_bind: Invalid credentials
ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 569, v1db1

or

ldap_simple_bind: Invalid credentials
ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1


Note: This article does not configure Kerberos tickets. Kerberos is not required for authentication to Active Directory, but it is required for SAMBA. So if you're looking for that I suggest you look for a different manual.

Enable a User for Unix Authentication

Log on to AD and start the “Active Directory Users and Computers” management console. Select an already created user or create a new one just like you would normally. The only thing different if you decide to create a new user is that you should not let the user change it's password at the next login. This would end up failing the login. After the installation set the UNIX attributes:
solarisadauth01.jpg
solarisadauth02.jpg

Test LDAP

The most simple way to test is LDAP is to do a ldapsearch. If this succeeds and output is returned you know you have a successful LDAP installation on Active Directory and that the bind user is also working properly:

bash-3.00# ldapsearch -b DC=nibshf,DC=local -h shftstc03 -D srv-unixauthentication@nibshf.local -w XXXXXXXXXXX uid=usrtest
version: 1
dn: CN=Nib Test,OU=Users,OU=00 - Delft,DC=nibshf,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Nib Test
sn: Test
givenName: Nib
distinguishedName: CN=Nib Test,OU=Users,OU=00 - Delft,DC=nibshf,DC=local
instanceType: 4
whenCreated: 20121213095140.0Z
whenChanged: 20121213095331.0Z
displayName: Nib Test
uSNCreated: 16691
uSNChanged: 16699
name: Nib Test
objectGUID:: 0leQmTXcD02mCnB4ZWb59w==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 129998659005725879
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAATSYfnx4kzRyWLpMMVAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: usrtest
sAMAccountType: 805306368
userPrincipalName: usrtest@nibshf.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=nibshf,DC=local
dSCorePropagationData: 20121213095140.0Z
dSCorePropagationData: 16010101000000.0Z
uid: usrtest
msSFU30Name: usrtest
msSFU30NisDomain: nibshf
uidNumber: 10000
gidNumber: 10000
unixHomeDirectory: /home/usrtest
loginShell: /bin/bash

If you experience errors or no output you could try to request all objectclasses without the baseDN to see if you make mistakes etc:

ldapsearch -b "" -h shftstc03 -D srv-unixauthentication@nibshf.local -w XXXXXXXXXXX -s base "objectclass=*"

Another error could come from the bind user you're using. The above format works for the ldapsearch command, but it will not work for the command to configure the LDAP client you'll need later on. That command requires the bind user to be in LDAP format:

bash-3.00# ldapsearch -b DC=nibshf,DC=local -h shftstc03 -D "CN=Service Account UNIX Authentication,OU=Users (Service Accounts),OU=0 - Global,DC=nibshf,DC=local" -w Beheer666 uid=usrtest
version: 1
dn: CN=Nib Test,OU=Users,OU=00 - Delft,DC=nibshf,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Nib Test
sn: Test
givenName: Nib
distinguishedName: CN=Nib Test,OU=Users,OU=00 - Delft,DC=nibshf,DC=local
instanceType: 4
whenCreated: 20121213095140.0Z
whenChanged: 20121213095331.0Z
displayName: Nib Test
uSNCreated: 16691
uSNChanged: 16699
name: Nib Test
objectGUID:: 0leQmTXcD02mCnB4ZWb59w==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 129998659005725879
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAATSYfnx4kzRyWLpMMVAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: usrtest
sAMAccountType: 805306368
userPrincipalName: usrtest@nibshf.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=nibshf,DC=local
dSCorePropagationData: 20121213095140.0Z
dSCorePropagationData: 16010101000000.0Z
uid: usrtest
msSFU30Name: usrtest
msSFU30NisDomain: nibshf
uidNumber: 10000
gidNumber: 10000
unixHomeDirectory: /home/usrtest
loginShell: /bin/bash
Note that the CN part is the Full User name in AD, and not the uid.

Configure the LDAP Client

Note: BEFORE you run the ldapclient command make a backup of /etc/nsswitch.conf. This will save you some work later on.

There are several ways to configure the LDAP client on Solaris, since we'll use a bind user we'll use the proxy method. Please notice the comments below the command:

ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN="CN=Service Account UNIX Authentication,OU=Users (Service Accounts),OU=0 - Global,DC=nibshf,DC=local" \
-a proxyPassword=Beheer666 \
-a defaultSearchBase=DC=nibshf,DC=local \
-a domainName=NIBSHF.LOCAL \
-a "defaultServerList=10.1.1.3" \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:DC=nibshf,DC=local?sub \
-a serviceSearchDescriptor=group:DC=nibshf,DC=local?sub

If you enter the “defaultServerList” options without quotes and with the FQDN name of the host you'll get the error below. You need to enter the host as an IP address:

Stopping autofs failed with (7). You may need to restart it manually for changes to take effect.
Error resetting system.
Recovering old system settings.
Stopping ldap failed with (7)
Error (1) while stopping services during reset
For troubleshooting purposes, if you want more output use: ldapclient manual -v \ for verbose output.

Created Files

You now should have two files listed in /var/ldap, ldap_client_cred and ldap_client_file:

bash-3.00# cat /var/ldap/ldap_client_cred
#
# Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead.
#
NS_LDAP_BINDDN= CN=Service Account UNIX Authentication,OU=Users (Service Accounts),OU=0 - Global,DC=nibshf,DC=local
NS_LDAP_BINDPASSWD= {NS1}b037196b7be6a05d7f
bash-3.00# cat /var/ldap/ldap_client_file
#
# Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead.
#
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= 10.1.1.3
NS_LDAP_SEARCH_BASEDN= DC=nibshf,DC=local
NS_LDAP_AUTH= simple
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:DC=nibshf,DC=local?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:DC=nibshf,DC=local?sub
NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=userPassword
NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=shadowFlag
NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=loginShell
NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory
NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn
NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid
NS_LDAP_ATTRIBUTEMAP= group:userpassword=userPassword
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user
NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group

Additional Configuration

Nsswitch.conf

If you followed the steps above correctly and to the point restore the backup of the nsswitch.conf file you created and only add the passwd and group sections listed below:

passwd:     files ldap
group:      files ldap

Also notice that the hosts section should be like this:

hosts:      files dns

This is also explained in this section but it is vital for LDAP to work properly.

Home Directory

Manually create a home directory for the user you created in Active Directory, see change_home_directories_and_profile for more information regarding home directories on solaris:

bash-3.00# cd /export/home/
bash-3.00# ls
bash-3.00# mkdir usrtest
bash-3.00# ls -l
total 2
drwxr-xr-x   2 root     root         512 Dec 13 13:29 usrtest
bash-3.00# chown usrtest usrtest/
bash-3.00# ls -l
total 2
drwxr-xr-x   2 usrtest  root         512 Dec 13 13:29 usrtest

Pam.conf

To be actually able to login using AD LDAP you'll need to configure PAM (Pluggable Authentication Modules) to also allow logging in through LDAP.

This is the added or changed lines in the configuration file:

login   auth sufficient         pam_unix_auth.so.1
login   auth required           pam_ldap.so.1
other   auth sufficient         pam_unix_auth.so.1
other   auth required           pam_ldap.so.1

and this is the resulting pam.conf file (notice the order in the different modules):

bash-3.00# cat /etc/pam.conf
#
#ident  "@(#)pam.conf   1.31    07/12/07 SMI"
#
# Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login   auth requisite          pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_cred.so.1
login   auth sufficient         pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1
login   auth required           pam_ldap.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth sufficient         pam_rhosts_auth.so.1
rlogin  auth requisite          pam_authtok_get.so.1
rlogin  auth required           pam_dhkeys.so.1
rlogin  auth required           pam_unix_cred.so.1
rlogin  auth required           pam_unix_auth.so.1
#
# Kerberized rlogin service
#
krlogin auth required           pam_unix_cred.so.1
krlogin auth required           pam_krb5.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh     auth sufficient         pam_rhosts_auth.so.1
rsh     auth required           pam_unix_cred.so.1
#
# Kerberized rsh service
#
krsh    auth required           pam_unix_cred.so.1
krsh    auth required           pam_krb5.so.1
#
# Kerberized telnet service
#
ktelnet auth required           pam_unix_cred.so.1
ktelnet auth required           pam_krb5.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp     auth requisite          pam_authtok_get.so.1
ppp     auth required           pam_dhkeys.so.1
ppp     auth required           pam_unix_cred.so.1
ppp     auth required           pam_unix_auth.so.1
ppp     auth required           pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other   auth requisite          pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth required           pam_unix_cred.so.1
other   auth sufficient         pam_unix_auth.so.1
other   auth required           pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd  auth required           pam_passwd_auth.so.1
#passwd  auth required         pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron    account required        pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other   account requisite       pam_roles.so.1
other   account sufficient      pam_unix_account.so.1
other   account required        pam_ldap.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other   session required        pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other   password required       pam_dhkeys.so.1
other   password requisite      pam_authtok_get.so.1
other   password requisite      pam_authtok_check.so.1
other   password required       pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

Testing

You can now test if the Solaris box recognizes the LDAP as a user source:

bash-3.00# getent passwd usrtest
usrtest:x:10000:10000:Nib Test:/home/usrtest:/bin/bash

Logging In

Now you should be able to log on using your AD account:

$ ssh -l usrtest shftstc02
usrtest@shftstc02's password:
Last login: Thu Dec 13 14:42:49 2012 from shftstc04.nibsh
/usr/openwin/bin/xauth:  creating new authority file /home/usrtest/.Xauthority
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
-bash-3.00$ pwd
/home/usrtest

Resources

You could leave a comment if you were logged in.
solarisadauth.txt · Last modified: 2021/09/24 00:25 (external edit)