Re: NTLM authentication

"Mark Rae" <mark@xxxxxxxxxxxxxxxxx> wrote in message news:u1CktXAMHHA.3952@xxxxxxxxxxxxxxxxxxxxxxx
"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message news:%23WOteNAMHHA.3944@xxxxxxxxxxxxxxxxxxxxxxx

Also, using above (DirectoryServices aka. ActiveDirectory) to authenticate a windows user is bad practice, I keep saying this.

Why? What would you recommend instead...?

Well, it depends on so many things, like the OS versions, Domain versions (if any) client types (windows non windows) and the final purpose of the authentication act.

Makes sense.

call Win32 LogonUser(), but while this validate a Windows user, it's purpose is to return an access token.

Yes - I've used that before when I've needed to know more than just a simple yes or no...

use the SSPI set of security API's, these can be used to authenticate using different protocols even for non Windows users. Unfortunately the V2 framework classes don't expose all of their functionalities. V3 does a far better job, but here they relate more to the WCF, than for generic authentication purposes.

OK - haven't really got into V3 yet...

On A W2K/W2K3 realm, you can use LDAP to authenticate against an AD domain, note here I'm talking about LDAP, that is using System.DirectoryServices.protocol classes!!! The same remark here as above, some network manager will not allow you to authenticate using LDAP against a corporate Directory.

Yes - that's what I'm currently doing via the code I offered a couple of replies up... I take your point about network managers, though - so far, I haven't come up against the scenario where I wasn't allowed to use AD to authenticate a user, so maybe I've just been lucky...


No, this snip from the above post...

using (DirectoryEntry objADEntry = new DirectoryEntry("LDAP://"; +
pstrDomain, pstrUser, pstrPassword))
isn't using LDAP, it's using DirectoryEntry which is a wrapper around ADSI, what I mean is using this:

using System.DirectoryServices.Protocols;
....
using (LdapConnection ldap = new LdapConnection("DomainName or DC name"))
{
LdapSessionOptions so = ldap.SessionOptions;
ldap.AuthType = AuthType.Kerberos; // or NTLM but ...
ldap.Bind(new NetworkCredential("username", "password", "domain"));
}
// done
...

this is far more lightweight and much faster than ADSI (DirectoryEntry).
Note also the Kerberos AuthType, this has the advantage that authentication costs are low, because of the life time of a kerb. ticket.

But again some System/network admins don't allow LDAP trafic, or only allow "DomainAdmin" Accounts, or "Exchange Admin"accounts to access the Directory. I'm consulting some financial businesses and none of them actually allow access to their Corporate (Windows) Directory server (no! they don't store client accounts ;-)), for obvious reasons. Some also don't want to have a bunch of private LDAP stores (ADAM and the like) floating around, that's why they apply policies that prevent LDAP trafic by closing the LDAP ports at a the firewall(s) and/or routers.


Anyway, using DirectoryServices just for authentication is not the right way of doing, just watch the amount of data passed when binding to the AD when doing so and you will understand why (but there is more). The Directory is kind of a DB which can store a lot of objects, authentication is part of the "authorization" process, that is, before you can access the objects stored in the directory, you have to prove "who you are" so that the DirectoryService can perform authorization controls. So basically it's the start of a longer transaction, but if you only perform the authentication step, you are needlessly hitting the service.

OK - I wasn't really aware of the internal going-on during the authentication process, but I guess it's a trade-off...

System.DirectoryServices
more processing overhead
managed code
returns a boolean, which is all I need


Use Ldap as illustrated above.

Win32 LogonUser()
less processing overhead
unmanaged code (pinvoke)
returns an access token, which I don't need and would rather not have anyway


But there is even better, if you have to authenticate in a W2K3 realm, even in V2.


It's funny that people never authenticate against, let's say against a SQL server, but find is quite usual to do it against a Directory server.

I authenticate against SQL Server for all my public websites - don't have a choice, as I've never found a 3rd-party ISP who would permit AD access...:-)

True, but this is not what I'm talking about, or are you telling me that here SQL server is only used for authentication??

Willy.


.

Relevant Pages

  • Re: check a user password
    ... ADAM user you'll have perform an LDAP Bind operation, ... However, as I said in another thread, LDAP is not an *authentication* protocol nor is "LDAP server" an authentication service. ... The LDAP bind operation is meant to "validate" the LDAP clients credentials in order, for the server, to be able to perform directory "authorization" checks. ... between a SQL client and a SQL server, or an authenticated session between a "Windows" client and a "File server" service. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: check a user password
    ... ADAM user you'll have perform an LDAP Bind operation, ... However, as I said in another thread, LDAP is not an *authentication* protocol nor is "LDAP ... client and a "File server" service (Windows or Samba, ... domain accounts" properties, one of the properties are the accounts ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Utilities for simple tasks
    ... Hi Charles, ... usable for anyone who can install programs on Windows. ... authentication modules) and LDAP. ... bit of effort to install a complete authentication framework based on ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Adding Solaris 10 machine to Active Directory Authentication
    ... This allows the Unix systems to access and share out windows style ... Unix style NFS shares. ... Authentication: Do this using Kerberos. ... Do this using LDAP but protect the LDAP bind and data ...
    (microsoft.public.windows.server.active_directory)
  • Re: open ldap or SUN one directory server
    ... Shouldn't you be using kerberos for authentication? ... Since you're dealing with both Windows and Solaris you might also ... is essentially Kerberos and LDAP married at gunpoint. ...
    (comp.sys.sun.admin)
Loading