Chris Ridd wrote:
On 9/8/05 2:57, SteveC <[EMAIL PROTECTED]> wrote:
It looks like I have got into the habit of replying to myself -- sorry
for the noise I am generating.
I have looked into the third of the above bullets and I think that I
have found out what is going on. In summary:
- When using ldapsearch, although I thought that I was binding to AD
with my UPN ([EMAIL PROTECTED]), ldapsearch was acually using my UNIX
account name, userid_2 (which is unfortunaley different from the prefiz
of my UPN, but is the same as the AD attribute sAMAccountName). It was
using this to authenticate to AD with the DIGEST-MD5 SASL method --
selecting auth-conf as I noted above.
- In my perl script, when I now use the sAMAccountname value (my UNIX
id) I can successfully authenticate. AD then compplains that I am only
using auth -- the domain security policy required auth-int or better (or
to run under SSL/TLS).
This now leaves me with a puzzle:
- Why is AD refusing to authenticate me using my UPN? According to the
AD documentation (for W2k3) digest hashes are calculated for a number
variants of alternate names (UPN and derivations of sAMAccountName) --
so why does it fail to allow me to log on -- evenn though it has
obviously 'matched' my account as after several attempts my account is
locked out.
- Presumably I am now going to need to get Authen::SASL::Cyrus working
so that I can use auth-int or auth-conf and so comform to our Domain
security policy (I could also use SSL/TLS but at present we don't have
that configured on our domain controllers). Any ideas on why the Cyrus
SASL gives 'Local error' even before generating any network traffic? I
certainly have digestmd5 enabled, and SASL2.
Steve,
I've got the author of the DIGEST-MD5 I-D next to me, and he might be able
to shed some likght on what's going wrong. Can you send a protocol trace
from the various clients?
Cheers,
Chris
I think that I might have spotted what's causing my problem:
This Microsoft technet article
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
explains how Microsoft pre-computes and saves certain MD5 hashes based
on combinations of account names (UPN and SamAccountName, DNS names,
fixed strings, and paswords -- in various combinations) [See Digest
Hashes section in the body]. These pre-computed hashes mean that AD
doesn't need to hold passwords in a reversible encryption format.[This
is a new feature in W2k3 -- W2k needs the reversible encryption
apparently if digest authentication is going to be used.]
In my environment, I have (don't ask my to justify why all the following
non-standard settings!):
- My UPN is [EMAIL PROTECTED] (where BASE is some string, i.e. not a real fqdn)
- my SamAccountName is name_2
- the forest root domain is ROOT.BASE
- the AD domain I belong to is XXXX.ROOT.BASE
- the flat domain name is XXXX
So, given all the above, when the 'A1' hash is calculated the 'realm'
used by DIGEST_MD5 is the one supplied by the domain controller which is
XXXX.ROOT.BASE. If this is the case, then the only entry from the table
in the above technet article that can ever work is if I provide the
SamAccountname -- then row 2 of the table (SamAccountName +
DNSDomainaname + password) will match a pre-computed hash.
Does that make sense?
If that is the case, then if the SASL & DIGEST_MD5 modules provided a
callback to enable the realm to be overridden, a user could provide one
of the Microsoft 'standard' values (in the case of a perverse
configuration like mine!) and things would work with the 'preferred'
UPN. [It still doesn't solve my auth-int/auth-conf follow-on
requirements however!]
Steve