form authetication?

[Guest]

Hi
Can anyone tell me which logon name (is NON "pre-Windows 2000" or the
"pre-Windows2000") is used for form authentication? Mine seems to work for
either one?! anyway to restrict that to just the NON "pre-Windows2000" one?

Also, I understand there is something called impersonation, can
impersonation be used with form authentication?

TIA

--

 

[Guest]

by the way, I am using form authentication with LDAP on AD.

 

[Joe Kaplan \(MVP - ADSI\)]

It depends on how you coded it.

Are you using a DirectoryEntry to bind to AD to authenticate the user? In
that case, the username syntax depends on the binding flags
(AuthenticationTypes) you specify.

The NT logon name (domain\user, where user is the sAMAccountName attribute
in AD) and the UserPrincipalName syntax (userPrincipalName attribute from
AD) will work in both simple and secure binds, so they are the most
flexible.

Joe K.

 

[Guest]

Hi Joe
Yes, I am using DirectoryEntry to bind but just to the NativeObject to force
authentication, I couldn't find any code sample showing with
AuthenticationType, is this the one that would imply which logon name to
use? Can you show me some code sample please?

Would it make any difference if I bind with NativeGUID?

By the way, thanks for your advise on my other thread.

It depends on how you coded it.

Are you using a DirectoryEntry to bind to AD to authenticate the user? In
that case, the username syntax depends on the binding flags
(AuthenticationTypes) you specify.

The NT logon name (domain\user, where user is the sAMAccountName attribute
in AD) and the UserPrincipalName syntax (userPrincipalName attribute from
AD) will work in both simple and secure binds, so they are the most
flexible.

Joe K.

 

[Joe Kaplan \(MVP - ADSI\)]

There are 4 possible username formats for an AD bind with DirectoryEntry
NT Account Name (domain\user)
userPrincipalName ([email protected], whatever is in the userPrincipalName
attribute)
plain username (whatever is in the sAMAccountName attribute)
distinguishedName

The first 2 can be used with any binding flags. The 3rd one can only be
used with AuthenticationTypes.Secure. The 4th one can only be used if
AuthenticationTypes.Secure is NOT specified.

I'd recommend you use AuthenticationTypes.Secure if you can, as it prevents
your credentials from going on the wire in plain text.

You can use NativeObject to force the bind. This is probably the fastest as
it doesn't load the property cache, so I'd recommend that.

HTH,

Joe K.

Hi Joe
Yes, I am using DirectoryEntry to bind but just to the NativeObject to
force
authentication, I couldn't find any code sample showing with
AuthenticationType, is this the one that would imply which logon name to
use? Can you show me some code sample please?

Would it make any difference if I bind with NativeGUID?

By the way, thanks for your advise on my other thread.

 

[Guest]

Hi Joe
I have been using the following lines of code to bind
DirectoryEntry entry = new DirectoryEntry(strpath, domain\user, pwd)
Object obj = entry.NativeObject

Do you mean I can change it to
DirectoryEntry entry = new DirectoryEntry(strpath, (e-mail address removed), pwd,
AuthenticationType.Secure)
Object obj = entry.NativeObject
?

TIA

 

[Guest]

Hi Joe
I just tried with the new syntax, it would still let me get by with either
userPrincipalName or the sAMAccountName. Does the path make any difference?
I have been using LDAP://dc=xxx, dc=com

TIA

 

[Joe Kaplan \(MVP - ADSI\)]

Yes, that is essentially it. AuthenticationTypes.Secure will use Kerberos
or NTLM to authenticate the user, then pass those credentials to AD via
LDAP.

You would want the entry.NativeObject in a try/catch block as well. And
don't forget to call Dispose in a Finally block on the DirectoryEntry object
to avoid memory leaks.

 

[Joe Kaplan \(MVP - ADSI\)]

It depends on what the error is. Generally, you don't need a path into the
directory to authenticate credentials. Just bind to rootDSE with the creds
you want to authenticate:

LDAP://rootDSE

Note however that if the current security context is a local machine account
(check WindowsIdentity.GetCurrent().Name), then you probably need to supply
a server or domain DNS name in your binding string as well:

LDAP://yourdomain.com/RootDSE

The "serverless" binding feature in ADSI/LDAP depends on the OS being able
to determine a domain controller from the identity of the current security
context, so if that is not a domain account, no domain will be found by
default.

HTH,

Joe K.

 

[Guest]

Hi Joe
The problem is for a user account say "Bill Gates" with a UPN
"(e-mail address removed)" and a sAMAccountName "billgates", I can login by typing
just bgates or billgates on the login page! Is it something to do with the
way I bind the DirectoryEntry? or just a configuration issue?

TIA

 

[Joe Kaplan \(MVP - ADSI\)]

I would need to know more details to be sure and would need to see your
code. Can you show a dump of the user object from ldp.exe so I can see that
actual attribute values from AD? Also, if you can show your code, that
would be great. Essentially, what you are saying should not work unless we
are missing an important detail.

Joe K.