Tim Alsop wrote:
Hi,
We have previously observed, that when MS AD is running on Windows 2000
or 2003, when an account has the DES key flag set, the client principal
name in cred cache on an XP workstation, after user logon is based on
the case of the name entered at logon screen, rather than using the case
of the account's SAMAccountName attribute + the domain name (in
uppercase) from AD directory. We were also aware that when no DES key
flag was set on an account the correct behaiviour was observed, such
that the principal name case was based on the case used to create the
account in AD, and the case of the userid entered on XP logon screen was
ignored. For example, a user logs onto their workstation, and enters
USeRname into the account field, and enters the appropriate password,
then after logon their ticket cache shows their tgt client principal
name as [EMAIL PROTECTED] This is the desired behaiviour because the tgt
principal name should not be based on the case of account name entered
when user logs on. We accept that there is an issue when DES flag, and
this was confirmed by MS as a bug, but MS have no desire to fix this. We
are 100% happy with this.
However, recently we discovered an issue when Windows 2003 SP1 Active
Directory is used. In this environment we are finding that the case of
the userid entered at the workstation during logon is used to determine
the client principal name case (even if an account doesn' t have the DES
flag set on) rather than using a consistent case, based on
SAMAccountName (which is what we observed before when using AD on
Windows 2003 before SP1 was installed).
To make the situation even stranger, we tried with another Windows 2003
SP1 domain, and we are finding it is working as expected, so is there an
issue with the way SP1 is installed, or perhaps a registry setting we
need to be aware of that is different on our 2 domains ?
Does anybody observe the same ? if so, do you know whether there is a
specific fix in SP1 which we can remove to make this work as it did
prior to SP1 ?
We ran into a similar problem with Java and mixed case account names.
This had to do with pre_auth and the salt. The Java code assumed it
knew the correct salt, and pre_auth type i.e. using the principal name
as typed by the user and tried to bypass the initial AS_REQ.
The KDC would then return KDC_ERR_PREAUTH_FAILED, assuming it had
previously sent the salt to the user with the KDC_ERR_PREAUTH_REQUIRED.
So is pre_auth_required set the same on both domains?
Has the case of the principals changed without changing the passwords?
i.e. the salt needs to remain the same even if the principal name changes.
What does ethereal show in the AS_REQ, AS_REP and KRB_ERROR packets?
(Our approach was to say principals are all lower case, and we changed
the few mixed case names and had the passwords reset at the same time.)
Thanks, Tim
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
