Authenticating Users Using Active Directory in Client-Server Application

Authenticating users using Active Directory in Client-Server Application

You do an NTLM/Kerberos/Negotiate SSPI exchange loop. There is a a full sample on MSDN for both the client and the server. To be clear: you do not use any sort of LDAP access explictily. Is the LSA (Local Security Authority) that talks with LDAP and establishes the identity of the client. If you are succesful in doing the entire SSPI loop, the authentication has succeeded already and the client identity is alread authenticated against the LDAP. If your server needs to know the client identity (eg. to know the use rname) it retrieves it from the security context resulted in the SSPI loop using the QueryContextAttributes(..., SECPKG_ATTR_NAMES,...) and retrieves the user name from the SecPkgContext_Names structure.

How to authenticate a user with Active Directory from a client using Integrated Windows Security?

The solution is to use NegotiateStream. This will establish a secure and authenticated communication with the server. The client can authenticate with integrated security by giving CredentialCache.DefaultNetworkCredentials to the NegotiateStream, the server can than act on the authenticated user with the NegotiateStream.RemoteIdentity.

How to authenticate users with a customer's (remote) active directory server

This scenario is one of the main scenarios supported by Windows Identity Foundation (WIF), provided they can expose their AD as a security token service (STS). They can do this using ADFS 2. The general approach is called identity federation. WIF integrates extremely well with ASP.Net.

There is lots of documentation on the web about WIF and identity federation with ADFS 2. For example, try this and also the documentation for the WIF SDK and Visual Studio tools.

authenticate user using active directory and get a token to be used elsewhere

You can't do that with AD and a client only, you need to involve a service in the authentication mechanism. If I were you, I'd send the username and password to the authentication service, the client shouldn't talk to the AD directly at all. And if you need some SSO, you can create a token in the authentication service. AD doesn't issue tokens, only you can, or another, more sophisticated service, like ADFS.



Related Topics



Leave a reply



Submit