-
Title
Specific user accounts unable to log in. -
Description
A user account is unable to log in even though it is Unix-Enabled.
# /opt/quest/bin/vastool isvas user username returns:
"username is not a VAS user, or a system account" (or similar)
# /opt/quest/bin/vastool -u host/ attrs username userPrincipalName returns nothing. -
Cause
The 'userPrinicalName' attribute is not set for the user's account. This can occur if you have upgraded from NT4 or if you are creating the users via scripting.
-
Resolution
To check if the 'userPrincipalName' (UPN) is set for the user run the following command replacing <username> with the user account having problems:
# /opt/quest/bin/vastool -u host/ attrs <username> userPrincipalName
If the above command does not show a userPrincipalNamethen one needs to be set. Please follow these steps:
1. Go into Active Directory Users and Computers.
2. Select the user account | right-click and select Properties, then select the Account tab.
3. Make sure the user logon name is filled in and a domain is selected. -
Additional Information
- Quest Authentication Services v3.x by default, uses the UPN (userPrincipalName) field for naming information and Active Directory (AD) queries. When there is no value for the UPN, QAS is unable to locate\cache the user.
For details on changing this behavior refer to Solution SOL18606, Configure QAS user and group objects to use different schema attributes for login and group name.
NOTE: In QAS 3.5 even when not using userPrincipalname for the username attribute, i.e. username-attr-name = samaccountname, QAS users still need to have a populated UPN, otherwise the user will not be cached. In QAS 4.x there is no longer a requirement for a UPN.
- Quest Authentication Services v3.x by default, uses the UPN (userPrincipalName) field for naming information and Active Directory (AD) queries. When there is no value for the UPN, QAS is unable to locate\cache the user.