-
标题
In oneway trust, users required to authenticate twice on login or sudo. -
说明
The first time a user logs in, they are prompted for their password. The first authentication will always fail. The second one succeeds. If they log out, and log right back in, the first password challenge will succeed. Same for sudo, the first password challenge will fail, the second will succeed. When they are challenged again later on, the first challenge will succeed. This is happening for both regular and permanently cached users.
This issue happened in a oneway trust configuration. Also the access control groups being domain local groups in forest 1 and the users are in forest 2.
Here is what the vas.conf looked like:
[vasd]
workstation-mode = true
[domain_realm]
myhost.forest1.com = FOREST1.COM
[libdefaults]
default_realm = FOREST1.COM
[vas_host_services]
FOREST2.com = {
krb5name = vastrust/qas-auth-svc@forest2.com
keytab = /etc/opt/quest/vas/qas-auth-svc.keytab
use-for-auth = true
password-change-interval = 0
}
-
解决办法
1 - Edit the /etc/opt/quest/vas/vas.conf file and changed the setting use-for-auth = true to use-for-auth = false.
Here is some information about the setting from the vas.conf man page.
use-for-auth =Default value: falseThis option is used to control whether or not this identity should be used when authenticating users. If set to true, a service ticket for the identity will be requested and the identity keytab will be used to validate the user's tickets. If false, then the default host identity will be used for the service ticket request and ticket validation. This is false by default as normal one way trust scenarios allow the users to request service tickets for the default host identity. This option should only be set to true when the trusted domain does not have any Kerberos trusts configured with the joined domain (i.e. only NTLM trusts are in place - a no-way trust configuration).2 - We receive information for access control groups from a few sources, two in particular are the PAC and token groups. Because the user isn't in the cache, for the initial login we use the PAC to determine group memberships.
/opt/quest/bin/vastool -u USERNAME auth -ps -S SERVICEACCT-FOR-ONEWAY -k PATHTOKEYTAB groups/opt/quest/bin/vastool -u SERVICEACCT-FOR-ONEWAY -k PATHTOKEYTAB user getgroups -lps USERNAMEThe above commands will show the groups we receive first from the PAC and secondly from the token group query. The first one will require the user to enter their password and the second one won't.Few options if access groups are not available at login:1. Use a Universal group for access control instead of Domain Local then run that second command again.2. Have the access control groups in the same domain as users rather than the one they are joined to. Then when we get the PAC it will have the groups used for access control.3 . Also ensure that the correct encryption type is on trust. For more information about this see KB186646