DSfW: Troubleshooting user authentication

  • 7010842
  • 27-Sep-2012
  • 31-Jan-2014

Environment

Novell Open Enterprise Server 11 SP1 (OES 11SP1)
Domain Services for Windows
DSFW

Situation

All users in the DSfW domain can not login in
A single user in the DSfW domain can not login in
A user can not login to a DSfW domain

Resolution

Possible reasons all users or a single user can not login to the domain.
How to troubleshoot and resolve login issues.

Are services running

Check that all DSfW services are running
Run xadcntrl validate to see if they are running.
Review TID 7001884


Password Policy Assignment

Check that a password policy is assigned to the partition or container where the user is located.  The attribute to look for is nspmPasswordpolicyDN

Use iManager | properties | other tab | nspmPasswordpolicyDN
or use ldapsearch (see TID 7003070)
Example with a base of o=novell:
LDAPCONF=/etc/opt/novell/xad/openldap/ldap.conf /usr/bin/ldapsearch -Y EXTERNAL -LLL -Q -b "o=novell" -s base nspmPasswordpolicyDN

It is common that during the install of DSfW the option to retain password policies is checked, but no password policy was assigned.
If the user or container does not have a nspmPasswordpolicyDN either use the Default Domain Policy, create a new password policy, or use an existing password policy.

To use the Default Domain Policy edit the /etc/opt/novell/xad/xad.ini and change XADRETAINPOLICIES = yes to XADRETAINPOLICIES = no

See TID 7010842 for more information on the xadretainpolicy setting.


Creating a new password policy
  1. Login to iManager | Expand the "Passwords" role | Select the "Password Policies" task.
  2. Select "New" to start the Password Policy Wizard In the "Container to create the policy in:" the default location of Password Policies is Security. If the DSfW server does not or is not going to hold a replica of root or security if security is partitioned it helps with the performance of DSfW to place the policy in the domain or in a container within a partition the server holds a replica of.  To change the location select the Browse button and browse to the container you wish to create the Password Policy in.
  3. Enter a Policy Name it is unique and easily identifiable, then continue on with the Password Policy Wizard selecting the necessary options as desired.  The "Synchronize Distribution Password" should be enabled by default.  This is necessary for non DSfW servers to set passwords.  You can verify in step 2 by clicking "View Options".
  4. When step 7 of 8 (Assign the Password Policy) is reached browse to the mapped container for the DSfW domain.  In this example it is o=novell.  If more than one partition is part of the domain assign to each partition that is part of the domain as well then click closed.
Run the ldapsearch again to verify nspmPasswordPolicyDN is returned.


Synchronize Distribution Password

If users change their password on a eDirectory server and not a DSfW server, Synchronize Distribution Password must be set in the password policy.  The "Default Domain Policy" password policy will have this set, but for password policies created with iManager "Synchronize Distribution Password" might not have been enabled.  
The Distribution Password on a non DSfW server updates the supplementalCredentials attribute which allows users to login to a domain.
See TID 7011636 for more information.

Check that uniquedomainid exists

The uniquedomainid is the attribute used to identify objects located within the DSfW domain.  If an object does not have this attribute or it is the wrong value, DSfW will not consider the object within the domain even if it is located in the mapped partition.

The first DSfW domain will always have a uniquedomainid value of 1049076.  For a child domain (not domain controller) a Different value will be used for all objects located with in the child domain.

Use iManager | properties | other tab | uniquedomainid
or use ldapsearch (see TID 7003070)
Example for user cn=user1,o=novell:
LDAPCONF=/etc/opt/novell/xad/openldap/ldap.conf /usr/bin/ldapsearch -Y EXTERNAL -LLL -Q -b "cn=user1,o=novell" uniquedomainid

Should return:
dn: cn=user1,o=novell
uniquedomainid: 1049076


Check that sAMAccountName exists and is correct

Use iManager | properties | other tab | sAMAccountName
or use ldapsearch (see TID 7003070)
Example for cn=user1,o=novell:
LDAPCONF=/etc/opt/novell/xad/openldap/ldap.conf /usr/bin/ldapsearch -Y EXTERNAL -LLL -Q -b cn=user1,o=novell sAMAccountName

Returned:
dn: cn=user1,o=novell
sAMAccountName: user2

In this Example the samaccountname is user2, when it should be user1.

The sAMAccountName is the attribute used to authenticate a user from XP/Win 7 workstations.
Example: user1

userPrincipalName can be used for authentication on XP/Win 7 workstations.
Example: user1@domain.com

If a user was renamed it is possible the old name is populated in samaccountname.  When samifying a user the first value returned for cn will be used.  eDirectory allows the cn to be multi valued where AD does not.  If the user was renamed and the samify picks up the old name first then the samaccount name will have the old name.

See TID 7010993 for more information the samaccountname being populated with the old cn.

See TID 7008032 for more info on userPrincipalName, samAccountName, and renaming users.

Check that supplementalCredentials exists

Use iManager | properties | other tab | supplementalCredentials
or use ldapsearch (see TID 7003070)
example:
LDAPCONF=/etc/opt/novell/xad/openldap/ldap.conf /usr/bin/ldapsearch -Y EXTERNAL -LLL -Q -b cn=user1,o=novell supplementalCredentials

Returns:
dn: cn=user1,o=novell
supplementalcredentials:: AAAAAMcDAAAAAAAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg
 ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAI
 AAgACAAIAAgACAAUAADACAAhAEBAFAAcgBpAG0AYQByAHkAOgBLAGUAcgBiAGUAcgBvAHMAMDMwMD
 AwMDAwMjAwMDIwMDFBMDAxQTAwNzgwMDAwMDAwM7003070DAwMDAwMDAwMDAwMDAwMDEwMDAwMDAwODAwMDA
 wMDkyMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzMDAwMDAwMDgwMDAwMDA5QTAwMDAwMDAwMDAwMDAw
 MDAwMDAwMDAwMTAwMDAwMDA4MDAwMDAwQTIwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDMwMDAwMDAwO
 DAwMDAwMEFBMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
 AwMDAwNDQwMDUzMDA0NjAwNTcwMDJFMDA0QzAwNDEwMDRFMDA3NTAwNzMwMDY1MDA3MjAwMzIwMDE
 1REE1RDA3RDY0OTkxMDgxNURBNUQwN0Q2NDk5MTA4MTVEQTVEMDdENjQ5OTEwODE1REE1RDA3RDY0
 OTkxMDgwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMB4AQAEAAFAAcgBpAG0AYQByAHkAO
 gBXAEQAaQBnAGUAcwB0ADMxMDAwMTA5MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwOUVFMzFDRkZCQ0
 UxNUJCNjI1NEE2NkRFMEVFRTQ1QUI5RUUzMUNGRkJDRTE1QkI2MjU0QTY2REUwRUVFNDVBQjFCMDA
 2MjY2NDFGQjg3OTU3ODA5NTZFNzg2MUZERkM2NEIwRkMzRDY4MjUwNUE2OTYwQjJBQzY5N0UwMEE4
 QjI0QjBGQzNENjgyNTA1QTY5NjBCMkFDNjk3RTAwQThCMjMyNUUxNkVFNjQzRjgzRTkwM0ZDMjQ2M
 UYwQUM0RjlBOUVFMzFDRkZCQ0UxNUJCNjI1NEE2NkRFMEVFRTQ1QUI5RUUzMUNGRkJDRTE1QkI2Mj
 U0QTY2REUwRUVFNDVBQjFCMDA2MjY2NDFGQjg3OTU3ODA5NTZFNzg2MUZERkM2EABAAAIAUABhAGM
 AawBhAGcAZQBzADRCMDA2NTAwNzIwMDYyMDA2NTAwNzIwMDZGMDA3MzAwMDAwMDU3MDA0NDAwNjkw
 MDY3MDA2NTAwNzMwMDc0MDA=

If nothing is returned for supplemental credentials check that a password policy is assigned, have the user login with the Novell Client, then do the ldapsearch again.
ndslogin can also be used to authenticate the user instead of Novell Client. 

What is required is the universal password be populated which will in turn update supplementalCredentials.   For this to happen the user must  have a password policy assigned and the user successfully login or set a new password.  Since DSfW requires a universal password, if all that exists is the ndsd password, the UP must be populated by a successful login or resetting of the password.

Check that the Universal Password and Distribution Password are in sync with the NDS Password

Use diagpwd to check that all passwords are in sync.
Example of using diagpwd to check users1's passwords, logging in with admin
./diagpwd 192.168.79.32 636 /etc/opt/novell/certs/SSCert.der cn=user1,ou=users,o=novell base cn=admin,o=novell

If it returns something like this
Object DN: cn=user1,ou=users,o=novell
EMail: [NONE]
Last Changed Date: 2007-03-20 21:48:28 Z
Password Status: Enabled, Set, UP != NDS
Distribution Password Status: Set
Simple Password Status: Not set
Password Policy DN: cn=Users UP Policy,ou=users,o=novell

We see that the Univeral Password is not the same and the NDS password.
Set the password with iManager or login with the Novell Client or ndslogin at a terminal to set the password.

The Password Status can be:
Disabled/Enabled
Not Set, Set
!=NDS (not equal to NDS)
UP != Simple (Universal Password not equal to Simple Password)

The desired output should show both the Universal Password and Distribution Password as being set.
Object DN: cn=user1,ou=users,o=novell
EMail: [NONE]
Last Changed Date: 2007-03-20 21:48:28 Z
Password Status: Enabled, Set
Distribution Password Status: Set
Simple Password Status: Set
Password Policy DN: cn=Users UP Policy,ou=users,o=novell

If there the Password Policy DN: does not list a password policy or is listing an invalid password policy review the Password Policy Assignment section of this TID.

Look at the event viewer on the workstation for any error

Look for errors and trouble shoot the error(s) seen in the event viewer.

tailf /var/log/messages and tailf /var/log/log.smbd (samba log) looking for error as the user logs in

Use tailf or tail -f  to follow the growth of the logfile.  Look for errors and troubleshoot errors that are reported in the log.

Look at kdc.log for errors

Some keys errors to look for are:
  1. Decrypt integrity check failed
  2. locked out
  3. client not found
1) Decrypt integrity check failed means a bad password was used to authenticate the user.
Below is a simple grep to find any instances of the Decrypt integrity check failed error for user1.  Change user1 in the command to the desired user.  The user name should not contain the context, just the user name as displayed in the samAccountName attribute.

grep -A1 -i 'Decrypt integrity check failed' /var/opt/novell/xad/log/kdc.log |grep -i user1
Returned:
Sep 26 10:43:16 oes11-dsfw1 krb5kdc[8569](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 151.155.212.135: PREAUTH_FAILED: user1@DSFW.LAN for krbtgt/DSFW.LAN@DSFW.LAN, Preauthentication failed
Sep 26 10:43:19 oes11-dsfw1 krb5kdc[8569](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 151.155.212.135: PREAUTH_FAILED: user1@DSFW.LAN for krbtgt/DSFW.LAN@DSFW.LAN, Preauthentication failed
Sep 26 10:43:22 oes11-dsfw1 krb5kdc[8569](info): AS_REQ (3 etypes {23 3 1}) 151.155.212.135: PREAUTH_FAILED: user1@DSFW.LAN for krbtgt/DSFW.LAN@DSFW.LAN, Preauthentication failed

To see sorted list of all Decrypt integrity checked failed errors do
grep -A1 -i 'Decrypt integrity check failed' /var/opt/novell/xad/log/kdc.log |grep -v 'Decrypt integrity check failed' |awk -F ')' '{print $3}' |grep -v '^$' |awk -F 'for' '{print $1}' |sort -n | uniq -c | sort -n | sed -e s/PREAUTH_FAILED:/BAD_PASSWORD:/g

2) Locked out means the intruder lockout was triggered and the account is now locked out
Below is a simple grep to find any instances of the locked out error for user1.  Change user1 in the command to the desired user.  The user name should not contain the context, just the user name as displayed in the samAccountName attribute.

grep -i 'locked out' /var/opt/novell/xad/log/kdc.log |grep -i user1
Returned:
Sep 26 11:05:03 oes11-dsfw1 krb5kdc[8569](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 151.155.212.135: Account Locked Out: user1@DSFW.LAN for krbtgt/DSFW.LAN@DSFW.LAN, Account Locked Out

3) Client not found means the object does not exist
Below is a simple grep to find any instances of the client not found error for user1.  Change user1 in the command to the desired user.  The user name should not contain the context, just the user name as displayed in the samAccountName attribute.

grep -i 'client not found' /var/opt/novell/xad/log/kdc.log |grep -i user1
Returned:
Sep 26 10:36:23 oes11-dsfw1 krb5kdc[8569](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 151.155.212.135: CLIENT_NOT_FOUND: user1@DSFW.LAN for krbtgt/DSFW.LAN@DSFW.LAN, Client not found in Kerberos database

Take a ldap/nmas trace while logging in with the user in question

Use ndstrace to take a  to take ldap/nmas trace from the DSfW server.  Look for any errors in the ndstrace regarding nmas.
See KB 7009602 for more information on performing a nmas trace.

Take a packet trace while logging in with the user in question

Use tcpdump or wireshark to take a packet trace from the DSfW server.  A packet trace from the workstation might also be necessary.
Before taking the trace turn off secure channel encryption
Turn off secure channel encryption:
A registry change is required to disable netlogon channel encryption. Change RequireSignOrSeal  from 1 to 0.
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters REG_DWORD  RequireSignOrSeal = 0 (Channel traffic need not be signed or sealed)
Use tcpdump to take a packet trace
tcpdump -n -v -i <interface> -s0 -w /<path>/<name_of_lan_trace>.cap
Press cntrl c to stop the trace.
To find the interface use ifconfig.  It will show the interfaces the the ip addresses.  Usually the interface is eth0 or eth1.
If there is only one IP address bound on the server another option is -i any.  Using any will listen on all interfaces.
When using tcpdump between a server and workstation on the same network a filter can be helpful in filtering traffic.
In this example of using tcpdump the workstations IP is 192.168.100.200,
the servers interface is eth0, and the output is written to/tmp/wk_join_dsfw.cap :
Example:
tcpdump -n -v -s0 -i eth0 'host 192.168.100.200' -w /tmp/wk_join_dsfw.cap

If might be necessary to look at the samba log (/var/log/log.smbd) with debug enabled as well. 
To enable smb debug open  /etc/samba/smb.conf and at the end of the [global] section add  log level =10 or from the terminal type smbcntrl -d 10
Restart of smbd or the other DSfW services is not needed.