LDAP user authentication error with VBScript from ASP

Hi,

I've been using the below code in my ASP page to authenticate users
against the Active Directory.
The code was working well but recently started throwing 'error
8007054b'. I search the net and understand that this could be due to
some security or network issue. The server guys say they havent
changed anything. I have another ASP.NET 2.0 application which is
working fine to authenticate users with System.DirectoryServices but
am stuck with the legacy ASP application breaking at ect("LDAP://
rootDSE")

Also the Active Directory maintenenace guys say that the server was
never marked as "Trust this computer for delegation" even when the
code was working so this doesnt seem to be a problem either.

Here's the relevant code:

strDomainUser = strDomain & "\" & strUserId
Set objRootDSE = GetObject("LDAP://rootDSE")
strADSPath = objRootDSE.Get("rootDomainNamingContext")
Set objDSObj = GetObject("LDAP:")
Set objAuth = objDSObj.OpenDSObject("LDAP://" & strADSPath,
strDomainUser, strPassword, 1)

Much appreciate any advice on this.

Best Regards,
mirin

That error means "the specified domain could not be contacted". That
usually happens when ADSI doesn't have enough information to figure out
which domain to use.

Since you are doing a serverless bind to the directory in your first call
(LDAP://rootDSE), ADSI tries to pick up the domain to use based on the
current security context of the executing thread. In ASP, impersonation is
always used. Since this code is probably running as anonymous (since the
code is performing authentication, I'm guessing the page itself did not use
Windows auth), it will impersonate the anonymous user. That user is
typically NOT a domain user, so it has no domain affiliation and thus the
ADSI code has this error.

You can usually get around this by supplying the DNS domain name of the
domain:

LDAP://domain.com/rootDSE

Also, I think you might be better off if your code skipped the bit with the
rootDomainNamingContext and just did this:

Set objDSObj = GetObject("LDAP:")
Set objAuth = objDSObj.OpenDSObject("LDAP://domain.com/rootDSE",
strDomainUser, strPassword, 1)

It is fine to use RootDSE as your target here and actually has a few
benefits in doing so.

In general, if the machine itself is domain joined, I'd suggest using
Windows authentication instead of forms auth in the first place. Windows
auth allows you to avoid this mess and will give you better scalability. If
you can't use IWA, you can use Basic auth. Basic auth essentially requires
you to use SSL, but you can't do forms auth like this securely without SSL
anyway (you weren't trying to, were you?), so you might as well just switch.
That's my $0.02.

..NET S.DS and ADSI go through the exact same code and have the same behavior
characteristics for the most part, so if the .NET code is working but your
script code isn't, it is likely because you are using slightly different
parameters or your operational parameters are slightly different.

HTH,

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"mirin" <zenstory@gmail.com> wrote in message
news:1188549604.881156.228070@q4g2000prc.googlegroups.com...
> Hi,
>
> I've been using the below code in my ASP page to authenticate users
> against the Active Directory.
> The code was working well but recently started throwing 'error
> 8007054b'. I search the net and understand that this could be due to
> some security or network issue. The server guys say they havent
> changed anything. I have another ASP.NET 2.0 application which is
> working fine to authenticate users with System.DirectoryServices but
> am stuck with the legacy ASP application breaking at ect("LDAP://
> rootDSE")
>
> Also the Active Directory maintenenace guys say that the server was
> never marked as "Trust this computer for delegation" even when the
> code was working so this doesnt seem to be a problem either.
>
> Here's the relevant code:
>
> strDomainUser = strDomain & "\" & strUserId
> Set objRootDSE = GetObject("LDAP://rootDSE")
> strADSPath = objRootDSE.Get("rootDomainNamingContext")
> Set objDSObj = GetObject("LDAP:")
> Set objAuth = objDSObj.OpenDSObject("LDAP://" & strADSPath,
> strDomainUser, strPassword, 1)
>
> Much appreciate any advice on this.
>
> Best Regards,
> mirin
>

On Aug 31, 11:46 pm, "Joe Kaplan"
<joseph.e.kap...@removethis.accenture.com> wrote:
> That error means "the specified domain could not be contacted". That
> usually happens when ADSI doesn't have enough information to figure out
> which domain to use.
>
> Since you are doing a serverless bind to the directory in your first call
> (LDAP://rootDSE), ADSI tries to pick up the domain to use based on the
> current security context of the executing thread. In ASP, impersonation is
> always used. Since this code is probably running as anonymous (since the
> code is performing authentication, I'm guessing the page itself did not use
> Windows auth), it will impersonate the anonymous user. That user is
> typically NOT a domain user, so it has no domain affiliation and thus the
> ADSI code has this error.
>
> You can usually get around this by supplying the DNS domain name of the
> domain:
>
> LDAP://domain.com/rootDSE
>
> Also, I think you might be better off if your code skipped the bit with the
> rootDomainNamingContext and just did this:
>
> Set objDSObj = GetObject("LDAP:")
> Set objAuth = objDSObj.OpenDSObject("LDAP://domain.com/rootDSE",
> strDomainUser, strPassword, 1)
>
> It is fine to use RootDSE as your target here and actually has a few
> benefits in doing so.
>
> In general, if the machine itself is domain joined, I'd suggest using
> Windows authentication instead of forms auth in the first place. Windows
> auth allows you to avoid this mess and will give you better scalability. If
> you can't use IWA, you can use Basic auth. Basic auth essentially requires
> you to use SSL, but you can't do forms auth like this securely without SSL
> anyway (you weren't trying to, were you?), so you might as well just switch.
> That's my $0.02.
>
> .NET S.DS and ADSI go through the exact same code and have the same behavior
> characteristics for the most part, so if the .NET code is working but your
> script code isn't, it is likely because you are using slightly different
> parameters or your operational parameters are slightly different.
>
> HTH,
>
> Joe K.
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"http://www.directoryprogramming.net
> --"mirin" <zenst...@gmail.com> wrote in message
>
> news:1188549604.881156.228070@q4g2000prc.googlegroups.com...
>
>
>
> > Hi,
>
> > I've been using the below code in my ASP page to authenticate users
> > against the Active Directory.
> > The code was working well but recently started throwing 'error
> > 8007054b'. I search the net and understand that this could be due to
> > some security or network issue. The server guys say they havent
> > changed anything. I have another ASP.NET 2.0 application which is
> > working fine to authenticate users with System.DirectoryServices but
> > am stuck with the legacy ASP application breaking at ect("LDAP://
> > rootDSE")
>
> > Also the Active Directory maintenenace guys say that the server was
> > never marked as "Trust this computer for delegation" even when the
> > code was working so this doesnt seem to be a problem either.
>
> > Here's the relevant code:
>
> > strDomainUser = strDomain & "\" & strUserId
> > Set objRootDSE = GetObject("LDAP://rootDSE")
> > strADSPath = objRootDSE.Get("rootDomainNamingContext")
> > Set objDSObj = GetObject("LDAP:")
> > Set objAuth = objDSObj.OpenDSObject("LDAP://" & strADSPath,
> > strDomainUser, strPassword, 1)
>
> > Much appreciate any advice on this.
>
> > Best Regards,
> > mirin- Hide quoted text -
>
> - Show quoted text -

Hi Joe,

Thanks a lot for the detailed explanation and advice. I tried skipping
the bit with the
rootDomainNamingContext and supplied "rootDSE" appended to the DNS and
it works perfect!!
Also, as per your advice, 'am considering switching to basic
authentication implementing SSL.

Thanks once again. I really appreciate your taking time to help with
this.

Best Regards,
Mirin