Active Directory Authentication in IIS 6


P

P Webster

We recently moved a web site that validated user credentials in Active
Directory from IIS 5.1 to IIS 6, and the validation code no longer works.
The web.config file is set to Windows authentication because all we do is
verify the user on the login form so we can redirect them to the appropriate
page based on their group.
The code to authenticate is:
Public Function IsAuthenticated(ByVal domain As String, ByVal username As
String, ByVal pwd As String) As Boolean
Dim domainAndUsername As String = domain & "\" & username
Dim entry As DirectoryEntry = New DirectoryEntry(_path,
domainAndUsername, pwd)
Try
'Bind to the native AdsObject to force authentication.
Dim obj As Object = entry.NativeObject
Dim search As DirectorySearcher = New DirectorySearcher(entry)
search.Filter = "(SAMAccountName=" & username & ")"
search.PropertiesToLoad.Add("cn")
Dim result As SearchResult = search.FindOne()
If (result Is Nothing) Then
Return False
End If
'Update the new path to the user in the directory.
_path = result.Path
_filterAttribute = CType(result.Properties("cn")(0), String)
Catch ex As Exception
Throw New Exception("Error authenticating user. " & ex.Message &
"<BR>" & ex.StackTrace.ToString)
End Try
Return True
End Function

In IIS 6, we have tried all possible combinations of directory security.

When we first moved the site to IIS 6, an error was generated by the above
code stating the parameter was incorrect, so we tried adding
AuthenticationTypes.None and AuthenticationTypes.Anonymous as the final
parameter for DirectoryEntry(... The result was a message returned as
"unknown user name or bad password. The user name and password entered were
correct, so I don't understand why that error was generated.

Any ideas would be greatly appreciated.

Paul
 
Ad

Advertisements

J

Joe Kaplan \(MVP - ADSI\)

It isn't actually necessary to search the directory to find the user if all
you want to do is verify their credentials. A bind operation with the
DirectoryEntry is sufficient. I generally recommend people just bind
against the RootDSE object on the domain controller:

entry = New DirectoryEntry("LDAP://yourdomain.com/RootDSE","domain\user",
"pwd", AuthenticationTypes.Secure)
Try
Dim obj As Object = entry.NativeObject
Return True
Catch Ex As COMException
'Make sure the HRESULT is actually "invalid credentials"
If Ex.ErrorCode <> &H8007052e Then Throw
Return False
Finally
If Not entry Is Nothing Then Entry.Dispose()
End Try

If you absolutely need to look up the user, you can.

It would be helpful to see the stack trace of the exception that is thrown
to see where the failure was as well.

Regarding authenticationtypes.None, don't use that with AD unless you add
SecureSocketsLayer. That forces an LDAP simple bind that passes your
credentials in plaintext on the network. Badness! "None" is often used
with ADAM to authenticate ADAM users, but it is still never secure unless
combined with some form of channel encryption.

AuthenticationTypes.Anonymous is not usually used with AD, as that disables
the Bind operation completely (which is exactly what you don't want here
since you need the bind to verify the credentials). In order to use it, you
must specify the credentials as empty strings. Note that AD 2003 doesn't
actually let you do anything unless you bind, so I would not expect this to
do you any good. It is mostly for use with non-AD LDAP directories that
allow anonymous searches.

There are tons of details about this stuff in my upcoming book (available in
May).

Joe K.
 
P

P Webster

Thanks for the response Joe, but I am not able to get past the following
line...
Dim obj As Object = entry.NativeObject.

The error message is:
The parameter is incorrect
The Stack Trace is
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at
System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_NativeObject() at
NMOWeb.FormsAuth.LdapAuthentication.IsAuthenticated(String domain, String
username, String pwd)

We just wanted to move this to a 2003 server, but it looks like we will need
to keep it on 2000 with IIS 5.1 until we can figure it out. The code works
flawlessly on IIS 5.1. Does this have something to do with KERBEROS or the
security settings in IIS 6?
 
J

Joe Kaplan \(MVP - ADSI\)

The parameter error could be Kerberos-related. What exact value are you
using for the path in this case? Is it possible that you are using the
incorrect DNS domain name in your path? Were you using the code I posted or
your own?

It could be Kerberos-related and it might have something to do with the
security settings in IIS6, but it might not too.

Joe K.
 
P

P Webster

Joe, I appreciate your help.

We have tried everything from the Domain Server name only, which worked fine
with IIS 5.1,
ADPath value of LDAP://DomServerName/DC=biz, DC=xxx, DC=yyy, DC=com
ADDomain value of DC=biz - this is the domain the user's select when logging
on to windows

to

ADPath value of LDAP://biz.xxx.yyy.com/DC=biz, DC=xxx, DC=yyy, DC=com
ADDomain value of DC=biz.xxx.yyy.com

and the IP address of the domain server

ADPath value of LDAP://172.000.000.00/DC=biz, DC=xxx, DC=yyy, DC=com
ADDomain value of DC=biz

And many combinations of the above.

We have someone trying to get it to work in ASP.NET 2.0 and we may just
update the application from ASP.NET 1.1
 
J

Joe Kaplan \(MVP - ADSI\)

If you can switch to .NET 2.0, you should just use the
ActiveDirectoryMembershipProvider if possible. It is cleaner and will scale
better.

I don't think .NET 2.0 will help otherwise as the error is happening down in
the ADSI/LDAP API level, not in managed code. That subsystem will not
change as a result of switching the version of the .NET wrapper (S.DS).

I'd suggest getting a copy of ldp.exe from the admin pack and trying that
out on the server to see what happens there. It is my favorite tool for
testing LDAP issues and checking queries and such.

All that said, something simple like this should work fine:

New DirectoryEntry("LDAP://biz.xxx.yyy.com/RootDSE","biz\username",
"password", AuthenticationTypes.Secure)

You generally always want to use DNS names with AD LDAP when possible to
avoid using NTLM auth (you generally want Kerberos when possible). Plain
host names and IP addresses are not as good of an idea.

RootDSE is always a safe object to try as well since all LDAP V3 servers
have one.

Another thing to do would be to look in the security and system event logs
to see if you are generating any funny errors there.

Best of luck,

Joe K.
 
Ad

Advertisements

P

P Webster

Thanks for your help Joe,

We had already checked all logs, and nothing was there.
I just installed ldp.exe and have no problems using the same credentials
used in the code to connect and bind.

In the mean time, we through a new hard drive in one of the development
machines and installed Windows Server 2003 with all the statdard defaults.
Added it to the domain. Installed the ASP.NET application. Tried to run the
app, and we have the exact same error message ("The parameter is incorrect")
and the same stack trace message.

I am beginning to think it has something to do with the default security
settings in IIS, but I am not sure where to look. Since we are not using
forms authentication or impersonation, I would think it wouldn't matter if
Anonymous Access is checked or not. On both machines, Anonymous Access is
checked, and Integrated Windows Authentication is checked. On the original
2003 box, we set up a special user account for anonymous access. On the new
machine, we left it with the default.

We will keep playing with the security settings and see if that fixes it
because it sure seems to me that the same code that works on IIS 5.1 would
work on IIS 6, but this isn't the first time I have been wrong.
 
Ad

Advertisements

P

P Webster

I just figured it out, and it appears that it was a coding error, which was a carryover from a Microsoft example.

The DirectoryEntry parameters being sent (and I might mention successfully in IIS 5.1) were:
entry = New DirectoryEntry("LDAP://biz.xxx.yyy.com/DC=biz, DC=xxx, DC=yyy, DC=com", "DC=biz\username", "password")
For some reason, the domain\username included "DC=" in front of it and IIS 5.1 must have dropped that off when trying to authenticate the user. When we removed the "DC=" and just used "biz\username", everything worked as expected.

It just goes to show you that the solution is not always complicated. Sit back, have a cup of coffee (decaffinated in this case), relax and get you mind off of the problem for a while. When you go back to it, take a fresh look and see what you can find.

Joe,
You have been a great help, keep up the good work!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top