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
