Hi,

I am trying to authenticate user credentials against Active Directory for an 
application that I'm working on.  I am currently using the adsopenobject 
function and specifying the kerberos flags (ADS_SECURE_AUTHENTICATION & 
ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not using 
the NULL value for my username & password.  The MSDN article "Binding With 
Encryption" says the following:

"ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with null 
credentials; that is, alternate credentials cannot be specified."

How can I use kerberos authentication and be able to specify credentials 
other than using the NULL value?  I am aware that NULL credentials would use 
the credentials of the current context, but that is not what I'm aiming for.

Thank you.

The article you mention must be incorrect as it is possible to get Kerb auth 
by specifying credentials.  Your client machine must be domain joined, you 
must have access to the necessary DCs to get the tickets required and must 
refer to the server by a name that can translate into an SPN, but otherwise 
it is possible.

However, you cannot guarantee that you will always get Kerb auth when the 
Negotiate package is being used (which is what ADSI uses when the Secure 
authentication flag is passed in).  All you can do is check to see if you 
got mutual auth after the fact by getting the proper flag from 
IADsObjectOptions.

If you want to do pure Kerb auth, you should be doing 
InitiateSecurityContext directly and specifying the auth package you want to 
use.  In general, you should not use ADSI for authentication anyway.  If you 
are already writing C++ code, just call InitiateSecurityContext or call 
LogonUser.

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
--
"cochee83"  wrote in message 
news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
> Hi,
>
> I am trying to authenticate user credentials against Active Directory for 
> an
> application that I'm working on.  I am currently using the adsopenobject
> function and specifying the kerberos flags (ADS_SECURE_AUTHENTICATION &
> ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not using
> the NULL value for my username & password.  The MSDN article "Binding With
> Encryption" says the following:
>
> "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with null
> credentials; that is, alternate credentials cannot be specified."
>
> How can I use kerberos authentication and be able to specify credentials
> other than using the NULL value?  I am aware that NULL credentials would 
> use
> the credentials of the current context, but that is not what I'm aiming 
> for.
>
> Thank you.
>
>

Thank you Joe,

I have a few follow-up questions:

1.  Why am I not guarantee that Kerb auth is used when the Negotiate package 
is being used?  When it is not used, what happens?  Are the credentials sent 
in plaintext?  Also, I've manually disabled Kerberos on the DC, and I've 
still been able to authenticate users against Active Directory via ADSI.  Is 
the mutual auth flag from IADsObjectOptions the only way to validate that 
Kerberos authentication was used?

2.  I did a google search on "InitiateSecurityContext" and only received 4 
results that were not very helpful.  Is there a link where I can find more 
information about this & "UserLogon"?

Thank you very much!


"Joe Kaplan" wrote:

> The article you mention must be incorrect as it is possible to get Kerb auth 
> by specifying credentials.  Your client machine must be domain joined, you 
> must have access to the necessary DCs to get the tickets required and must 
> refer to the server by a name that can translate into an SPN, but otherwise 
> it is possible.
> 
> However, you cannot guarantee that you will always get Kerb auth when the 
> Negotiate package is being used (which is what ADSI uses when the Secure 
> authentication flag is passed in).  All you can do is check to see if you 
> got mutual auth after the fact by getting the proper flag from 
> IADsObjectOptions.
> 
> If you want to do pure Kerb auth, you should be doing 
> InitiateSecurityContext directly and specifying the auth package you want to 
> use.  In general, you should not use ADSI for authentication anyway.  If you 
> are already writing C++ code, just call InitiateSecurityContext or call 
> LogonUser.
> 
> 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
> --
> "cochee83"  wrote in message 
> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
> > Hi,
> >
> > I am trying to authenticate user credentials against Active Directory for 
> > an
> > application that I'm working on.  I am currently using the adsopenobject
> > function and specifying the kerberos flags (ADS_SECURE_AUTHENTICATION &
> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not using
> > the NULL value for my username & password.  The MSDN article "Binding With
> > Encryption" says the following:
> >
> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with null
> > credentials; that is, alternate credentials cannot be specified."
> >
> > How can I use kerberos authentication and be able to specify credentials
> > other than using the NULL value?  I am aware that NULL credentials would 
> > use
> > the credentials of the current context, but that is not what I'm aiming 
> > for.
> >
> > Thank you.
> >
> > 
> 
> 
>

Sorry, I meant to type InitializeSecurityContext, not Initiate.  It was a 
little late for me.  :)  That is a function in the SDK, so you should find 
it in MSDN.

The negotiate auth package selects between Kerberos and NTLM.  If Kerberos 
is possible, then it will use Kerberos, otherwise it will select NTLM and 
use that instead.  Credentials are not sent in plaintext in either case 
although Kerberos is generally much more secure than NTLM.

As I said before, there are a number of reasons why Kerberos may not be 
selected.  If the client isn't domain joined or can't reach a KDC, that 
would prevent it.  Also, if the client can't find a service that matches the 
servicePrincipalName it is trying to get a ticket for, that would prevent 
Kerberos.

With ADSI, the only way I know of for sure to determine if Kerberos actually 
was used is to check that flag.

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
--
"cochee83"  wrote in message 
news:29476231-5B06-4AF6-B9AF-ECC17D0D133B@microsoft.com...
> Thank you Joe,
>
> I have a few follow-up questions:
>
> 1.  Why am I not guarantee that Kerb auth is used when the Negotiate 
> package
> is being used?  When it is not used, what happens?  Are the credentials 
> sent
> in plaintext?  Also, I've manually disabled Kerberos on the DC, and I've
> still been able to authenticate users against Active Directory via ADSI. 
> Is
> the mutual auth flag from IADsObjectOptions the only way to validate that
> Kerberos authentication was used?
>
> 2.  I did a google search on "InitiateSecurityContext" and only received 4
> results that were not very helpful.  Is there a link where I can find more
> information about this & "UserLogon"?
>
> Thank you very much!
>
>
> "Joe Kaplan" wrote:
>
>> The article you mention must be incorrect as it is possible to get Kerb 
>> auth
>> by specifying credentials.  Your client machine must be domain joined, 
>> you
>> must have access to the necessary DCs to get the tickets required and 
>> must
>> refer to the server by a name that can translate into an SPN, but 
>> otherwise
>> it is possible.
>>
>> However, you cannot guarantee that you will always get Kerb auth when the
>> Negotiate package is being used (which is what ADSI uses when the Secure
>> authentication flag is passed in).  All you can do is check to see if you
>> got mutual auth after the fact by getting the proper flag from
>> IADsObjectOptions.
>>
>> If you want to do pure Kerb auth, you should be doing
>> InitiateSecurityContext directly and specifying the auth package you want 
>> to
>> use.  In general, you should not use ADSI for authentication anyway.  If 
>> you
>> are already writing C++ code, just call InitiateSecurityContext or call
>> LogonUser.
>>
>> 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
>> --
>> "cochee83"  wrote in message
>> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
>> > Hi,
>> >
>> > I am trying to authenticate user credentials against Active Directory 
>> > for
>> > an
>> > application that I'm working on.  I am currently using the 
>> > adsopenobject
>> > function and specifying the kerberos flags (ADS_SECURE_AUTHENTICATION &
>> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not 
>> > using
>> > the NULL value for my username & password.  The MSDN article "Binding 
>> > With
>> > Encryption" says the following:
>> >
>> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with 
>> > null
>> > credentials; that is, alternate credentials cannot be specified."
>> >
>> > How can I use kerberos authentication and be able to specify 
>> > credentials
>> > other than using the NULL value?  I am aware that NULL credentials 
>> > would
>> > use
>> > the credentials of the current context, but that is not what I'm aiming
>> > for.
>> >
>> > Thank you.
>> >
>> >
>>
>>
>>

If I decide to use LogonUser instead of InitializeSecurityContext, how do I 
specify to use Kerberos?  Online, they've mentioned to specify 
"LOGON32_LOGON_NEW_CREDENTIALS" for LogonType, and "LOGON32_PROVIDER_WINNT50" 
for LogonProvider, but I would just like confirmation on this.

Thanks!


"Joe Kaplan" wrote:

> Sorry, I meant to type InitializeSecurityContext, not Initiate.  It was a 
> little late for me.  :)  That is a function in the SDK, so you should find 
> it in MSDN.
> 
> The negotiate auth package selects between Kerberos and NTLM.  If Kerberos 
> is possible, then it will use Kerberos, otherwise it will select NTLM and 
> use that instead.  Credentials are not sent in plaintext in either case 
> although Kerberos is generally much more secure than NTLM.
> 
> As I said before, there are a number of reasons why Kerberos may not be 
> selected.  If the client isn't domain joined or can't reach a KDC, that 
> would prevent it.  Also, if the client can't find a service that matches the 
> servicePrincipalName it is trying to get a ticket for, that would prevent 
> Kerberos.
> 
> With ADSI, the only way I know of for sure to determine if Kerberos actually 
> was used is to check that flag.
> 
> 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
> --
> "cochee83"  wrote in message 
> news:29476231-5B06-4AF6-B9AF-ECC17D0D133B@microsoft.com...
> > Thank you Joe,
> >
> > I have a few follow-up questions:
> >
> > 1.  Why am I not guarantee that Kerb auth is used when the Negotiate 
> > package
> > is being used?  When it is not used, what happens?  Are the credentials 
> > sent
> > in plaintext?  Also, I've manually disabled Kerberos on the DC, and I've
> > still been able to authenticate users against Active Directory via ADSI. 
> > Is
> > the mutual auth flag from IADsObjectOptions the only way to validate that
> > Kerberos authentication was used?
> >
> > 2.  I did a google search on "InitiateSecurityContext" and only received 4
> > results that were not very helpful.  Is there a link where I can find more
> > information about this & "UserLogon"?
> >
> > Thank you very much!
> >
> >
> > "Joe Kaplan" wrote:
> >
> >> The article you mention must be incorrect as it is possible to get Kerb 
> >> auth
> >> by specifying credentials.  Your client machine must be domain joined, 
> >> you
> >> must have access to the necessary DCs to get the tickets required and 
> >> must
> >> refer to the server by a name that can translate into an SPN, but 
> >> otherwise
> >> it is possible.
> >>
> >> However, you cannot guarantee that you will always get Kerb auth when the
> >> Negotiate package is being used (which is what ADSI uses when the Secure
> >> authentication flag is passed in).  All you can do is check to see if you
> >> got mutual auth after the fact by getting the proper flag from
> >> IADsObjectOptions.
> >>
> >> If you want to do pure Kerb auth, you should be doing
> >> InitiateSecurityContext directly and specifying the auth package you want 
> >> to
> >> use.  In general, you should not use ADSI for authentication anyway.  If 
> >> you
> >> are already writing C++ code, just call InitiateSecurityContext or call
> >> LogonUser.
> >>
> >> 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
> >> --
> >> "cochee83"  wrote in message
> >> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
> >> > Hi,
> >> >
> >> > I am trying to authenticate user credentials against Active Directory 
> >> > for
> >> > an
> >> > application that I'm working on.  I am currently using the 
> >> > adsopenobject
> >> > function and specifying the kerberos flags (ADS_SECURE_AUTHENTICATION &
> >> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not 
> >> > using
> >> > the NULL value for my username & password.  The MSDN article "Binding 
> >> > With
> >> > Encryption" says the following:
> >> >
> >> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with 
> >> > null
> >> > credentials; that is, alternate credentials cannot be specified."
> >> >
> >> > How can I use kerberos authentication and be able to specify 
> >> > credentials
> >> > other than using the NULL value?  I am aware that NULL credentials 
> >> > would
> >> > use
> >> > the credentials of the current context, but that is not what I'm aiming
> >> > for.
> >> >
> >> > Thank you.
> >> >
> >> >
> >>
> >>
> >> 
> 
> 
>

Also, this article http://support.microsoft.com/kb/180548/ says the 
following about InitializeSecurityContext:

"The biggest downside to this type of logon is that you cannot access remote 
network resources after impersonating a network type logon. If your 
application is calling LogonUser with the LOGON32_LOGON_INTERACTIVE logon 
type to workaround Windows NT's inability to perform delegation, then the 
SSPI logon/validation will probably not be a viable alternative."

Who are they referring to?  If User1 logs onto a workstation as a domain 
user, opens an application, and logs on as User2 which authenticates against 
the domain, does that mean that User1 will not have access to resources in 
the domain?



"cochee83" wrote:

> 
> If I decide to use LogonUser instead of InitializeSecurityContext, how do I 
> specify to use Kerberos?  Online, they've mentioned to specify 
> "LOGON32_LOGON_NEW_CREDENTIALS" for LogonType, and "LOGON32_PROVIDER_WINNT50" 
> for LogonProvider, but I would just like confirmation on this.
> 
> Thanks!
> 
> 
> "Joe Kaplan" wrote:
> 
> > Sorry, I meant to type InitializeSecurityContext, not Initiate.  It was a 
> > little late for me.  :)  That is a function in the SDK, so you should find 
> > it in MSDN.
> > 
> > The negotiate auth package selects between Kerberos and NTLM.  If Kerberos 
> > is possible, then it will use Kerberos, otherwise it will select NTLM and 
> > use that instead.  Credentials are not sent in plaintext in either case 
> > although Kerberos is generally much more secure than NTLM.
> > 
> > As I said before, there are a number of reasons why Kerberos may not be 
> > selected.  If the client isn't domain joined or can't reach a KDC, that 
> > would prevent it.  Also, if the client can't find a service that matches the 
> > servicePrincipalName it is trying to get a ticket for, that would prevent 
> > Kerberos.
> > 
> > With ADSI, the only way I know of for sure to determine if Kerberos actually 
> > was used is to check that flag.
> > 
> > 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
> > --
> > "cochee83"  wrote in message 
> > news:29476231-5B06-4AF6-B9AF-ECC17D0D133B@microsoft.com...
> > > Thank you Joe,
> > >
> > > I have a few follow-up questions:
> > >
> > > 1.  Why am I not guarantee that Kerb auth is used when the Negotiate 
> > > package
> > > is being used?  When it is not used, what happens?  Are the credentials 
> > > sent
> > > in plaintext?  Also, I've manually disabled Kerberos on the DC, and I've
> > > still been able to authenticate users against Active Directory via ADSI. 
> > > Is
> > > the mutual auth flag from IADsObjectOptions the only way to validate that
> > > Kerberos authentication was used?
> > >
> > > 2.  I did a google search on "InitiateSecurityContext" and only received 4
> > > results that were not very helpful.  Is there a link where I can find more
> > > information about this & "UserLogon"?
> > >
> > > Thank you very much!
> > >
> > >
> > > "Joe Kaplan" wrote:
> > >
> > >> The article you mention must be incorrect as it is possible to get Kerb 
> > >> auth
> > >> by specifying credentials.  Your client machine must be domain joined, 
> > >> you
> > >> must have access to the necessary DCs to get the tickets required and 
> > >> must
> > >> refer to the server by a name that can translate into an SPN, but 
> > >> otherwise
> > >> it is possible.
> > >>
> > >> However, you cannot guarantee that you will always get Kerb auth when the
> > >> Negotiate package is being used (which is what ADSI uses when the Secure
> > >> authentication flag is passed in).  All you can do is check to see if you
> > >> got mutual auth after the fact by getting the proper flag from
> > >> IADsObjectOptions.
> > >>
> > >> If you want to do pure Kerb auth, you should be doing
> > >> InitiateSecurityContext directly and specifying the auth package you want 
> > >> to
> > >> use.  In general, you should not use ADSI for authentication anyway.  If 
> > >> you
> > >> are already writing C++ code, just call InitiateSecurityContext or call
> > >> LogonUser.
> > >>
> > >> 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
> > >> --
> > >> "cochee83"  wrote in message
> > >> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
> > >> > Hi,
> > >> >
> > >> > I am trying to authenticate user credentials against Active Directory 
> > >> > for
> > >> > an
> > >> > application that I'm working on.  I am currently using the 
> > >> > adsopenobject
> > >> > function and specifying the kerberos flags (ADS_SECURE_AUTHENTICATION &
> > >> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not 
> > >> > using
> > >> > the NULL value for my username & password.  The MSDN article "Binding 
> > >> > With
> > >> > Encryption" says the following:
> > >> >
> > >> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with 
> > >> > null
> > >> > credentials; that is, alternate credentials cannot be specified."
> > >> >
> > >> > How can I use kerberos authentication and be able to specify 
> > >> > credentials
> > >> > other than using the NULL value?  I am aware that NULL credentials 
> > >> > would
> > >> > use
> > >> > the credentials of the current context, but that is not what I'm aiming
> > >> > for.
> > >> >
> > >> > Thank you.
> > >> >
> > >> >
> > >>
> > >>
> > >> 
> > 
> > 
> >

I think LogonUser always uses NTLM as of now, although that may change at 
some point.  I'm not sure why it works that way.  You don't get to specify 
though.

The only way I know for sure how to specify Kerberos be used is to use 
InitializeSecurityContext.  The MSDN docs have more specifics.

If you just want to authenticate the user, then it doesn't really matter 
what kind of token you get back.

I'd suggest you follow up on a different newsgroup 
(microsoft.public.platformsdk.security) to get some additional info.  This 
newsgroup is intended to cover people trying to adminstrate IIS using ADSI, 
so your post is kind of off topic and the real experts on this subject 
likely aren't paying attention here.  I'd also explain why you need to 
authenticate with Kerberos and what you are trying to achieve.

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
--
"cochee83"  wrote in message 
news:0FEAB446-A38E-4F32-925F-0F9DD192F33E@microsoft.com...
>
> If I decide to use LogonUser instead of InitializeSecurityContext, how do 
> I
> specify to use Kerberos?  Online, they've mentioned to specify
> "LOGON32_LOGON_NEW_CREDENTIALS" for LogonType, and 
> "LOGON32_PROVIDER_WINNT50"
> for LogonProvider, but I would just like confirmation on this.
>
> Thanks!
>
>
> "Joe Kaplan" wrote:
>
>> Sorry, I meant to type InitializeSecurityContext, not Initiate.  It was a
>> little late for me.  :)  That is a function in the SDK, so you should 
>> find
>> it in MSDN.
>>
>> The negotiate auth package selects between Kerberos and NTLM.  If 
>> Kerberos
>> is possible, then it will use Kerberos, otherwise it will select NTLM and
>> use that instead.  Credentials are not sent in plaintext in either case
>> although Kerberos is generally much more secure than NTLM.
>>
>> As I said before, there are a number of reasons why Kerberos may not be
>> selected.  If the client isn't domain joined or can't reach a KDC, that
>> would prevent it.  Also, if the client can't find a service that matches 
>> the
>> servicePrincipalName it is trying to get a ticket for, that would prevent
>> Kerberos.
>>
>> With ADSI, the only way I know of for sure to determine if Kerberos 
>> actually
>> was used is to check that flag.
>>
>> 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
>> --
>> "cochee83"  wrote in message
>> news:29476231-5B06-4AF6-B9AF-ECC17D0D133B@microsoft.com...
>> > Thank you Joe,
>> >
>> > I have a few follow-up questions:
>> >
>> > 1.  Why am I not guarantee that Kerb auth is used when the Negotiate
>> > package
>> > is being used?  When it is not used, what happens?  Are the credentials
>> > sent
>> > in plaintext?  Also, I've manually disabled Kerberos on the DC, and 
>> > I've
>> > still been able to authenticate users against Active Directory via 
>> > ADSI.
>> > Is
>> > the mutual auth flag from IADsObjectOptions the only way to validate 
>> > that
>> > Kerberos authentication was used?
>> >
>> > 2.  I did a google search on "InitiateSecurityContext" and only 
>> > received 4
>> > results that were not very helpful.  Is there a link where I can find 
>> > more
>> > information about this & "UserLogon"?
>> >
>> > Thank you very much!
>> >
>> >
>> > "Joe Kaplan" wrote:
>> >
>> >> The article you mention must be incorrect as it is possible to get 
>> >> Kerb
>> >> auth
>> >> by specifying credentials.  Your client machine must be domain joined,
>> >> you
>> >> must have access to the necessary DCs to get the tickets required and
>> >> must
>> >> refer to the server by a name that can translate into an SPN, but
>> >> otherwise
>> >> it is possible.
>> >>
>> >> However, you cannot guarantee that you will always get Kerb auth when 
>> >> the
>> >> Negotiate package is being used (which is what ADSI uses when the 
>> >> Secure
>> >> authentication flag is passed in).  All you can do is check to see if 
>> >> you
>> >> got mutual auth after the fact by getting the proper flag from
>> >> IADsObjectOptions.
>> >>
>> >> If you want to do pure Kerb auth, you should be doing
>> >> InitiateSecurityContext directly and specifying the auth package you 
>> >> want
>> >> to
>> >> use.  In general, you should not use ADSI for authentication anyway. 
>> >> If
>> >> you
>> >> are already writing C++ code, just call InitiateSecurityContext or 
>> >> call
>> >> LogonUser.
>> >>
>> >> 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
>> >> --
>> >> "cochee83"  wrote in message
>> >> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
>> >> > Hi,
>> >> >
>> >> > I am trying to authenticate user credentials against Active 
>> >> > Directory
>> >> > for
>> >> > an
>> >> > application that I'm working on.  I am currently using the
>> >> > adsopenobject
>> >> > function and specifying the kerberos flags 
>> >> > (ADS_SECURE_AUTHENTICATION &
>> >> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not
>> >> > using
>> >> > the NULL value for my username & password.  The MSDN article 
>> >> > "Binding
>> >> > With
>> >> > Encryption" says the following:
>> >> >
>> >> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with
>> >> > null
>> >> > credentials; that is, alternate credentials cannot be specified."
>> >> >
>> >> > How can I use kerberos authentication and be able to specify
>> >> > credentials
>> >> > other than using the NULL value?  I am aware that NULL credentials
>> >> > would
>> >> > use
>> >> > the credentials of the current context, but that is not what I'm 
>> >> > aiming
>> >> > for.
>> >> >
>> >> > Thank you.
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

Hi Joe,

In one of the other posts, you described the reason for not recommending 
ADSI as follows:

"The issue with ADSI is the way it does connection caching.  It will open a 
new socket for each new user that binds and then close that connection when 
it is done.  The problem here is that the socket will sit in "time wait" 
status for 1 minute by default and will not be usable.  You only have so 
many wildcard ports available to open sockets to the server, so if they are 
all sitting in time wait, you can't connect anymore.  You see this happen in 
higher volume apps that are doing lots of authentications.  You would need 
to get a few hundred connections going at once to get into trouble though."

In large networks, domains have multiple domain controllers so if one of 
them runs out of sockets, another domain controller could possibly be 
utilized.  What do you think about this claim?

Thanks,
Alejandro






"Joe Kaplan" wrote:

> I think LogonUser always uses NTLM as of now, although that may change at 
> some point.  I'm not sure why it works that way.  You don't get to specify 
> though.
> 
> The only way I know for sure how to specify Kerberos be used is to use 
> InitializeSecurityContext.  The MSDN docs have more specifics.
> 
> If you just want to authenticate the user, then it doesn't really matter 
> what kind of token you get back.
> 
> I'd suggest you follow up on a different newsgroup 
> (microsoft.public.platformsdk.security) to get some additional info.  This 
> newsgroup is intended to cover people trying to adminstrate IIS using ADSI, 
> so your post is kind of off topic and the real experts on this subject 
> likely aren't paying attention here.  I'd also explain why you need to 
> authenticate with Kerberos and what you are trying to achieve.
> 
> 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
> --
> "cochee83"  wrote in message 
> news:0FEAB446-A38E-4F32-925F-0F9DD192F33E@microsoft.com...
> >
> > If I decide to use LogonUser instead of InitializeSecurityContext, how do 
> > I
> > specify to use Kerberos?  Online, they've mentioned to specify
> > "LOGON32_LOGON_NEW_CREDENTIALS" for LogonType, and 
> > "LOGON32_PROVIDER_WINNT50"
> > for LogonProvider, but I would just like confirmation on this.
> >
> > Thanks!
> >
> >
> > "Joe Kaplan" wrote:
> >
> >> Sorry, I meant to type InitializeSecurityContext, not Initiate.  It was a
> >> little late for me.  :)  That is a function in the SDK, so you should 
> >> find
> >> it in MSDN.
> >>
> >> The negotiate auth package selects between Kerberos and NTLM.  If 
> >> Kerberos
> >> is possible, then it will use Kerberos, otherwise it will select NTLM and
> >> use that instead.  Credentials are not sent in plaintext in either case
> >> although Kerberos is generally much more secure than NTLM.
> >>
> >> As I said before, there are a number of reasons why Kerberos may not be
> >> selected.  If the client isn't domain joined or can't reach a KDC, that
> >> would prevent it.  Also, if the client can't find a service that matches 
> >> the
> >> servicePrincipalName it is trying to get a ticket for, that would prevent
> >> Kerberos.
> >>
> >> With ADSI, the only way I know of for sure to determine if Kerberos 
> >> actually
> >> was used is to check that flag.
> >>
> >> 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
> >> --
> >> "cochee83"  wrote in message
> >> news:29476231-5B06-4AF6-B9AF-ECC17D0D133B@microsoft.com...
> >> > Thank you Joe,
> >> >
> >> > I have a few follow-up questions:
> >> >
> >> > 1.  Why am I not guarantee that Kerb auth is used when the Negotiate
> >> > package
> >> > is being used?  When it is not used, what happens?  Are the credentials
> >> > sent
> >> > in plaintext?  Also, I've manually disabled Kerberos on the DC, and 
> >> > I've
> >> > still been able to authenticate users against Active Directory via 
> >> > ADSI.
> >> > Is
> >> > the mutual auth flag from IADsObjectOptions the only way to validate 
> >> > that
> >> > Kerberos authentication was used?
> >> >
> >> > 2.  I did a google search on "InitiateSecurityContext" and only 
> >> > received 4
> >> > results that were not very helpful.  Is there a link where I can find 
> >> > more
> >> > information about this & "UserLogon"?
> >> >
> >> > Thank you very much!
> >> >
> >> >
> >> > "Joe Kaplan" wrote:
> >> >
> >> >> The article you mention must be incorrect as it is possible to get 
> >> >> Kerb
> >> >> auth
> >> >> by specifying credentials.  Your client machine must be domain joined,
> >> >> you
> >> >> must have access to the necessary DCs to get the tickets required and
> >> >> must
> >> >> refer to the server by a name that can translate into an SPN, but
> >> >> otherwise
> >> >> it is possible.
> >> >>
> >> >> However, you cannot guarantee that you will always get Kerb auth when 
> >> >> the
> >> >> Negotiate package is being used (which is what ADSI uses when the 
> >> >> Secure
> >> >> authentication flag is passed in).  All you can do is check to see if 
> >> >> you
> >> >> got mutual auth after the fact by getting the proper flag from
> >> >> IADsObjectOptions.
> >> >>
> >> >> If you want to do pure Kerb auth, you should be doing
> >> >> InitiateSecurityContext directly and specifying the auth package you 
> >> >> want
> >> >> to
> >> >> use.  In general, you should not use ADSI for authentication anyway. 
> >> >> If
> >> >> you
> >> >> are already writing C++ code, just call InitiateSecurityContext or 
> >> >> call
> >> >> LogonUser.
> >> >>
> >> >> 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
> >> >> --
> >> >> "cochee83"  wrote in message
> >> >> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
> >> >> > Hi,
> >> >> >
> >> >> > I am trying to authenticate user credentials against Active 
> >> >> > Directory
> >> >> > for
> >> >> > an
> >> >> > application that I'm working on.  I am currently using the
> >> >> > adsopenobject
> >> >> > function and specifying the kerberos flags 
> >> >> > (ADS_SECURE_AUTHENTICATION &
> >> >> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm not
> >> >> > using
> >> >> > the NULL value for my username & password.  The MSDN article 
> >> >> > "Binding
> >> >> > With
> >> >> > Encryption" says the following:
> >> >> >
> >> >> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with
> >> >> > null
> >> >> > credentials; that is, alternate credentials cannot be specified."
> >> >> >
> >> >> > How can I use kerberos authentication and be able to specify
> >> >> > credentials
> >> >> > other than using the NULL value?  I am aware that NULL credentials
> >> >> > would
> >> >> > use
> >> >> > the credentials of the current context, but that is not what I'm 
> >> >> > aiming
> >> >> > for.
> >> >> >
> >> >> > Thank you.
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >> 
> 
> 
>

This limitation applies to the client machine as well as the DC, so you run 
the risk of port exhaustion on the client (the web server in this case) just 
as much as you run the risk of port exhaustion on the DC (which also amounts 
to a denial of service attack on your own domain controller).

If scalability is required, just don't use ADSI.  It is a poor architectural 
choice for this type of application.  There are many better ways to go.

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
--
"cochee83"  wrote in message 
news:3B0033ED-F79C-403D-9493-F523E83401A9@microsoft.com...
> Hi Joe,
>
> In one of the other posts, you described the reason for not recommending
> ADSI as follows:
>
> "The issue with ADSI is the way it does connection caching.  It will open 
> a
> new socket for each new user that binds and then close that connection 
> when
> it is done.  The problem here is that the socket will sit in "time wait"
> status for 1 minute by default and will not be usable.  You only have so
> many wildcard ports available to open sockets to the server, so if they 
> are
> all sitting in time wait, you can't connect anymore.  You see this happen 
> in
> higher volume apps that are doing lots of authentications.  You would need
> to get a few hundred connections going at once to get into trouble 
> though."
>
> In large networks, domains have multiple domain controllers so if one of
> them runs out of sockets, another domain controller could possibly be
> utilized.  What do you think about this claim?
>
> Thanks,
> Alejandro
>
>
>
>
>
>
> "Joe Kaplan" wrote:
>
>> I think LogonUser always uses NTLM as of now, although that may change at
>> some point.  I'm not sure why it works that way.  You don't get to 
>> specify
>> though.
>>
>> The only way I know for sure how to specify Kerberos be used is to use
>> InitializeSecurityContext.  The MSDN docs have more specifics.
>>
>> If you just want to authenticate the user, then it doesn't really matter
>> what kind of token you get back.
>>
>> I'd suggest you follow up on a different newsgroup
>> (microsoft.public.platformsdk.security) to get some additional info. 
>> This
>> newsgroup is intended to cover people trying to adminstrate IIS using 
>> ADSI,
>> so your post is kind of off topic and the real experts on this subject
>> likely aren't paying attention here.  I'd also explain why you need to
>> authenticate with Kerberos and what you are trying to achieve.
>>
>> 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
>> --
>> "cochee83"  wrote in message
>> news:0FEAB446-A38E-4F32-925F-0F9DD192F33E@microsoft.com...
>> >
>> > If I decide to use LogonUser instead of InitializeSecurityContext, how 
>> > do
>> > I
>> > specify to use Kerberos?  Online, they've mentioned to specify
>> > "LOGON32_LOGON_NEW_CREDENTIALS" for LogonType, and
>> > "LOGON32_PROVIDER_WINNT50"
>> > for LogonProvider, but I would just like confirmation on this.
>> >
>> > Thanks!
>> >
>> >
>> > "Joe Kaplan" wrote:
>> >
>> >> Sorry, I meant to type InitializeSecurityContext, not Initiate.  It 
>> >> was a
>> >> little late for me.  :)  That is a function in the SDK, so you should
>> >> find
>> >> it in MSDN.
>> >>
>> >> The negotiate auth package selects between Kerberos and NTLM.  If
>> >> Kerberos
>> >> is possible, then it will use Kerberos, otherwise it will select NTLM 
>> >> and
>> >> use that instead.  Credentials are not sent in plaintext in either 
>> >> case
>> >> although Kerberos is generally much more secure than NTLM.
>> >>
>> >> As I said before, there are a number of reasons why Kerberos may not 
>> >> be
>> >> selected.  If the client isn't domain joined or can't reach a KDC, 
>> >> that
>> >> would prevent it.  Also, if the client can't find a service that 
>> >> matches
>> >> the
>> >> servicePrincipalName it is trying to get a ticket for, that would 
>> >> prevent
>> >> Kerberos.
>> >>
>> >> With ADSI, the only way I know of for sure to determine if Kerberos
>> >> actually
>> >> was used is to check that flag.
>> >>
>> >> 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
>> >> --
>> >> "cochee83"  wrote in message
>> >> news:29476231-5B06-4AF6-B9AF-ECC17D0D133B@microsoft.com...
>> >> > Thank you Joe,
>> >> >
>> >> > I have a few follow-up questions:
>> >> >
>> >> > 1.  Why am I not guarantee that Kerb auth is used when the Negotiate
>> >> > package
>> >> > is being used?  When it is not used, what happens?  Are the 
>> >> > credentials
>> >> > sent
>> >> > in plaintext?  Also, I've manually disabled Kerberos on the DC, and
>> >> > I've
>> >> > still been able to authenticate users against Active Directory via
>> >> > ADSI.
>> >> > Is
>> >> > the mutual auth flag from IADsObjectOptions the only way to validate
>> >> > that
>> >> > Kerberos authentication was used?
>> >> >
>> >> > 2.  I did a google search on "InitiateSecurityContext" and only
>> >> > received 4
>> >> > results that were not very helpful.  Is there a link where I can 
>> >> > find
>> >> > more
>> >> > information about this & "UserLogon"?
>> >> >
>> >> > Thank you very much!
>> >> >
>> >> >
>> >> > "Joe Kaplan" wrote:
>> >> >
>> >> >> The article you mention must be incorrect as it is possible to get
>> >> >> Kerb
>> >> >> auth
>> >> >> by specifying credentials.  Your client machine must be domain 
>> >> >> joined,
>> >> >> you
>> >> >> must have access to the necessary DCs to get the tickets required 
>> >> >> and
>> >> >> must
>> >> >> refer to the server by a name that can translate into an SPN, but
>> >> >> otherwise
>> >> >> it is possible.
>> >> >>
>> >> >> However, you cannot guarantee that you will always get Kerb auth 
>> >> >> when
>> >> >> the
>> >> >> Negotiate package is being used (which is what ADSI uses when the
>> >> >> Secure
>> >> >> authentication flag is passed in).  All you can do is check to see 
>> >> >> if
>> >> >> you
>> >> >> got mutual auth after the fact by getting the proper flag from
>> >> >> IADsObjectOptions.
>> >> >>
>> >> >> If you want to do pure Kerb auth, you should be doing
>> >> >> InitiateSecurityContext directly and specifying the auth package 
>> >> >> you
>> >> >> want
>> >> >> to
>> >> >> use.  In general, you should not use ADSI for authentication 
>> >> >> anyway.
>> >> >> If
>> >> >> you
>> >> >> are already writing C++ code, just call InitiateSecurityContext or
>> >> >> call
>> >> >> LogonUser.
>> >> >>
>> >> >> 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
>> >> >> --
>> >> >> "cochee83"  wrote in message
>> >> >> news:EE52BB71-5878-4D04-8D33-136F71E3E198@microsoft.com...
>> >> >> > Hi,
>> >> >> >
>> >> >> > I am trying to authenticate user credentials against Active
>> >> >> > Directory
>> >> >> > for
>> >> >> > an
>> >> >> > application that I'm working on.  I am currently using the
>> >> >> > adsopenobject
>> >> >> > function and specifying the kerberos flags
>> >> >> > (ADS_SECURE_AUTHENTICATION &
>> >> >> > ADS_USE_SEALING).  But I'm also specifying user credentials; I'm 
>> >> >> > not
>> >> >> > using
>> >> >> > the NULL value for my username & password.  The MSDN article
>> >> >> > "Binding
>> >> >> > With
>> >> >> > Encryption" says the following:
>> >> >> >
>> >> >> > "ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called 
>> >> >> > with
>> >> >> > null
>> >> >> > credentials; that is, alternate credentials cannot be specified."
>> >> >> >
>> >> >> > How can I use kerberos authentication and be able to specify
>> >> >> > credentials
>> >> >> > other than using the NULL value?  I am aware that NULL 
>> >> >> > credentials
>> >> >> > would
>> >> >> > use
>> >> >> > the credentials of the current context, but that is not what I'm
>> >> >> > aiming
>> >> >> > for.
>> >> >> >
>> >> >> > Thank you.
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Hi,

Is there a reason why I shouldn't use "ldap_bind" to authenticate users?  It 
looks like it doesn't allow me to authenticate domain users nor specify the 
kerberos protocol, but I just want to confirm.

My ultimate goal is to authenticate user logons against Active Directory for 
my company's application.  My current strategy is to use Kerberos for 
Standard logons (thick client), and use SSL for user logons over the web.  Am 
I approaching this the right way?

Thanks!

LDAP bind using the Windows LDAP API definitely supports Kerberos 
authentication.  The GSS-SPNEGO SASL mechanism uses the standard Windows 
Negotiate protocol which will attempt to use Kerberos whenever possible. 
Also, when authenticating users using LDAP to AD, you are by definition 
authenticating domain users.  AD only contains domain users, so only domain 
users can be authenticated by it.

If you are careful in your design, you can build a scalable authentication 
solution based on LDAP bind authentication.

The question would be why you would write code to do this in the first 
place.  IIS is perfectly capable of authenticating domain users for you by 
enabling IWA or Basic auth, so why code for this?  It does all the heavy 
lifting for you.

The suggested alternative to using LDAP bind for authentication against AD 
would be to code directly to the SSPI API.

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
--
"cochee83"  wrote in message 
news:6D921B9D-031D-41BF-B81F-33345E974E81@microsoft.com...
> Hi,
>
> Is there a reason why I shouldn't use "ldap_bind" to authenticate users? 
> It
> looks like it doesn't allow me to authenticate domain users nor specify 
> the
> kerberos protocol, but I just want to confirm.
>
> My ultimate goal is to authenticate user logons against Active Directory 
> for
> my company's application.  My current strategy is to use Kerberos for
> Standard logons (thick client), and use SSL for user logons over the web. 
> Am
> I approaching this the right way?
>
> Thanks!
>
>

Hi,

I'm having a difficult time trying to understand the relationships between 
the LDAP API, SSPI, and ADSI.  I've read several articles in msdn, but they 
just leave me even more confused.  I know that LDAP is a protocol for 
communicating with a directory service application such as Active Directory.  
I know I can use all 3 of them for user authentication via Kerberos, although 
ADSI is not a scalable solution and the LDAP API requires a lot of code that 
can be similarly executed by IIS.

1.  Does SSPI authenticate users over LDAP ?
2.  Does the implementation of SSPI make use of the LDAP API ?
3.  Does IIS make use of the LDAP API ?
4.  Does ADSI make use of SSPI, which in turn makes use of the LDAP API ?

I apologize for all these questions, but I'm trying to gain some perspective 
as to why there are so many ways to implement the same thing, and how they 
are related to each other.

Thank you very much!

Alejandro




"Joe Kaplan" wrote:

> LDAP bind using the Windows LDAP API definitely supports Kerberos 
> authentication.  The GSS-SPNEGO SASL mechanism uses the standard Windows 
> Negotiate protocol which will attempt to use Kerberos whenever possible. 
> Also, when authenticating users using LDAP to AD, you are by definition 
> authenticating domain users.  AD only contains domain users, so only domain 
> users can be authenticated by it.
> 
> If you are careful in your design, you can build a scalable authentication 
> solution based on LDAP bind authentication.
> 
> The question would be why you would write code to do this in the first 
> place.  IIS is perfectly capable of authenticating domain users for you by 
> enabling IWA or Basic auth, so why code for this?  It does all the heavy 
> lifting for you.
> 
> The suggested alternative to using LDAP bind for authentication against AD 
> would be to code directly to the SSPI API.
> 
> 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
> --
> "cochee83"  wrote in message 
> news:6D921B9D-031D-41BF-B81F-33345E974E81@microsoft.com...
> > Hi,
> >
> > Is there a reason why I shouldn't use "ldap_bind" to authenticate users? 
> > It
> > looks like it doesn't allow me to authenticate domain users nor specify 
> > the
> > kerberos protocol, but I just want to confirm.
> >
> > My ultimate goal is to authenticate user logons against Active Directory 
> > for
> > my company's application.  My current strategy is to use Kerberos for
> > Standard logons (thick client), and use SSL for user logons over the web. 
> > Am
> > I approaching this the right way?
> >
> > Thanks!
> >
> > 
> 
> 
>

Here are a few things that might help clarify:

 - ADSI is a set of COM interfaces which implements a provider-based 
mechanism for accessing a variety of different data stores.  LDAP is one of 
the providers for ADSI and it basically wraps the Windows LDAP API.
 - The Windows LDAP API, wldap32.dll, provides an implementation of the 
standard LDAP API with a variety of Windows-specific extensions added.  LDAP 
itself can be used as an authentication mechanism using the Bind operation 
and supports both plaintext credentials (LDAP "simple" bind) and an 
extensible authentication provider model called SASL.  Windows LDAP provides 
3 SASL extensions, GSS-SPNEGO (Windows negotiate protocol) DIGEST and 
EXTERNAL (used for SSL client cert auth).
 - SSPI is another provider-based API in Windows that implements the 
standard Windows authentication protocols, Negotiate, Kerberos, NTLM, Digest 
and SSL.  Negotiate is essentially a meta protocol that selects between 
Kerberos and NTLM and provides backwards compatibility to older clients 
(very old at this point) that cannot support Kerberos (everything since 
Win2K can).

The layer models looks like:

ADSI
  |
LDAP API (via LDAP provider in ADSI)
  |
SSPI (via SASL in LDAP)
  |
raw authentication protocols

IIS uses SSPI directly when authenticating users, although it may in some 
cases use higher level wrapper functions such as LogonUser and LsaLogonUser 
to access SSPI.  Nothing in Windows uses LDAP for authentication directly.

So, my recommendation is to use IIS for authentication directly if you can 
since there is no great reason to write this code if you don't have to.  The 
server can do it for you.  If you must write authentication code, consider 
programming to SSPI first (or using LogonUser if possible).  If there is a 
reason why you can't use SSPI directly (firewall only allow LDAP accesss or 
something), the consider using the LDAP API and be very careful how you 
handle reuse of connections (the key to scalability).  Don't use ADSI for 
authentication if you need to scale because it won't.

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
--
"cochee83"  wrote in message 
news:D20A8777-7A76-4E51-A929-1C4E12B7591B@microsoft.com...
> Hi,
>
> I'm having a difficult time trying to understand the relationships between
> the LDAP API, SSPI, and ADSI.  I've read several articles in msdn, but 
> they
> just leave me even more confused.  I know that LDAP is a protocol for
> communicating with a directory service application such as Active 
> Directory.
> I know I can use all 3 of them for user authentication via Kerberos, 
> although
> ADSI is not a scalable solution and the LDAP API requires a lot of code 
> that
> can be similarly executed by IIS.
>
> 1.  Does SSPI authenticate users over LDAP ?
> 2.  Does the implementation of SSPI make use of the LDAP API ?
> 3.  Does IIS make use of the LDAP API ?
> 4.  Does ADSI make use of SSPI, which in turn makes use of the LDAP API ?
>
> I apologize for all these questions, but I'm trying to gain some 
> perspective
> as to why there are so many ways to implement the same thing, and how they
> are related to each other.
>
> Thank you very much!
>
> Alejandro
>
>
>
>
> "Joe Kaplan" wrote:
>
>> LDAP bind using the Windows LDAP API definitely supports Kerberos
>> authentication.  The GSS-SPNEGO SASL mechanism uses the standard Windows
>> Negotiate protocol which will attempt to use Kerberos whenever possible.
>> Also, when authenticating users using LDAP to AD, you are by definition
>> authenticating domain users.  AD only contains domain users, so only 
>> domain
>> users can be authenticated by it.
>>
>> If you are careful in your design, you can build a scalable 
>> authentication
>> solution based on LDAP bind authentication.
>>
>> The question would be why you would write code to do this in the first
>> place.  IIS is perfectly capable of authenticating domain users for you 
>> by
>> enabling IWA or Basic auth, so why code for this?  It does all the heavy
>> lifting for you.
>>
>> The suggested alternative to using LDAP bind for authentication against 
>> AD
>> would be to code directly to the SSPI API.
>>
>> 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
>> --
>> "cochee83"  wrote in message
>> news:6D921B9D-031D-41BF-B81F-33345E974E81@microsoft.com...
>> > Hi,
>> >
>> > Is there a reason why I shouldn't use "ldap_bind" to authenticate 
>> > users?
>> > It
>> > looks like it doesn't allow me to authenticate domain users nor specify
>> > the
>> > kerberos protocol, but I just want to confirm.
>> >
>> > My ultimate goal is to authenticate user logons against Active 
>> > Directory
>> > for
>> > my company's application.  My current strategy is to use Kerberos for
>> > Standard logons (thick client), and use SSL for user logons over the 
>> > web.
>> > Am
>> > I approaching this the right way?
>> >
>> > Thanks!
>> >
>> >
>>
>>
>>

Thanks a lot Joe.  This helped out tremendously.  

Supposed I want my code to be able to be compatible with other directories.  
If this is the case, then I don't think SSPI would work because it seems to 
be an interface specific to Microsoft.  I would think that the LDAP API would 
have to be used, along with the "GSSAPI" SASL mechanism since the 
"GSS-SPNEGO" is not supported by other non-Windows directories.  In your 
other columns, you mentioned to use SSL LDAP in order to have a common 
denominator, which would mean to utilize the "External" SASL mechanism, but 
you did not mention "GSSAPI".

Thanks,
Alejandro



"Joe Kaplan" wrote:

> Here are a few things that might help clarify:
> 
>  - ADSI is a set of COM interfaces which implements a provider-based 
> mechanism for accessing a variety of different data stores.  LDAP is one of 
> the providers for ADSI and it basically wraps the Windows LDAP API.
>  - The Windows LDAP API, wldap32.dll, provides an implementation of the 
> standard LDAP API with a variety of Windows-specific extensions added.  LDAP 
> itself can be used as an authentication mechanism using the Bind operation 
> and supports both plaintext credentials (LDAP "simple" bind) and an 
> extensible authentication provider model called SASL.  Windows LDAP provides 
> 3 SASL extensions, GSS-SPNEGO (Windows negotiate protocol) DIGEST and 
> EXTERNAL (used for SSL client cert auth).
>  - SSPI is another provider-based API in Windows that implements the 
> standard Windows authentication protocols, Negotiate, Kerberos, NTLM, Digest 
> and SSL.  Negotiate is essentially a meta protocol that selects between 
> Kerberos and NTLM and provides backwards compatibility to older clients 
> (very old at this point) that cannot support Kerberos (everything since 
> Win2K can).
> 
> The layer models looks like:
> 
> ADSI
>   |
> LDAP API (via LDAP provider in ADSI)
>   |
> SSPI (via SASL in LDAP)
>   |
> raw authentication protocols
> 
> IIS uses SSPI directly when authenticating users, although it may in some 
> cases use higher level wrapper functions such as LogonUser and LsaLogonUser 
> to access SSPI.  Nothing in Windows uses LDAP for authentication directly.
> 
> So, my recommendation is to use IIS for authentication directly if you can 
> since there is no great reason to write this code if you don't have to.  The 
> server can do it for you.  If you must write authentication code, consider 
> programming to SSPI first (or using LogonUser if possible).  If there is a 
> reason why you can't use SSPI directly (firewall only allow LDAP accesss or 
> something), the consider using the LDAP API and be very careful how you 
> handle reuse of connections (the key to scalability).  Don't use ADSI for 
> authentication if you need to scale because it won't.
> 
> 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
> --

If you need to authenticate against other directories, then LDAP is usually 
the way to go.  The only authentication method that is mentioned in the 
actual LDAP spec is simple bind, so it is the only thing you can count on 
for cross platform support.  Note that it is only secure when combined with 
transport security like SSL though.

Kerberos/GSSAPI is less common outside of Windows, so I would not expect to 
be able to use that on many other directories.  Digest is an option with 
many other directories although you must be careful with username formats.

In general, you'll likely need to provide a variety of options and some 
configurability if you want to have a lot of reach into other systems.

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
--
"cochee83"  wrote in message 
news:71CCB5E2-164A-448A-99B9-7B5BA2CA6AA7@microsoft.com...
>
> Thanks a lot Joe.  This helped out tremendously.
>
> Supposed I want my code to be able to be compatible with other 
> directories.
> If this is the case, then I don't think SSPI would work because it seems 
> to
> be an interface specific to Microsoft.  I would think that the LDAP API 
> would
> have to be used, along with the "GSSAPI" SASL mechanism since the
> "GSS-SPNEGO" is not supported by other non-Windows directories.  In your
> other columns, you mentioned to use SSL LDAP in order to have a common
> denominator, which would mean to utilize the "External" SASL mechanism, 
> but
> you did not mention "GSSAPI".
>
> Thanks,
> Alejandro
>
>
>
> "Joe Kaplan" wrote:
>
>> Here are a few things that might help clarify:
>>
>>  - ADSI is a set of COM interfaces which implements a provider-based
>> mechanism for accessing a variety of different data stores.  LDAP is one 
>> of
>> the providers for ADSI and it basically wraps the Windows LDAP API.
>>  - The Windows LDAP API, wldap32.dll, provides an implementation of the
>> standard LDAP API with a variety of Windows-specific extensions added. 
>> LDAP
>> itself can be used as an authentication mechanism using the Bind 
>> operation
>> and supports both plaintext credentials (LDAP "simple" bind) and an
>> extensible authentication provider model called SASL.  Windows LDAP 
>> provides
>> 3 SASL extensions, GSS-SPNEGO (Windows negotiate protocol) DIGEST and
>> EXTERNAL (used for SSL client cert auth).
>>  - SSPI is another provider-based API in Windows that implements the
>> standard Windows authentication protocols, Negotiate, Kerberos, NTLM, 
>> Digest
>> and SSL.  Negotiate is essentially a meta protocol that selects between
>> Kerberos and NTLM and provides backwards compatibility to older clients
>> (very old at this point) that cannot support Kerberos (everything since
>> Win2K can).
>>
>> The layer models looks like:
>>
>> ADSI
>>   |
>> LDAP API (via LDAP provider in ADSI)
>>   |
>> SSPI (via SASL in LDAP)
>>   |
>> raw authentication protocols
>>
>> IIS uses SSPI directly when authenticating users, although it may in some
>> cases use higher level wrapper functions such as LogonUser and 
>> LsaLogonUser
>> to access SSPI.  Nothing in Windows uses LDAP for authentication 
>> directly.
>>
>> So, my recommendation is to use IIS for authentication directly if you 
>> can
>> since there is no great reason to write this code if you don't have to. 
>> The
>> server can do it for you.  If you must write authentication code, 
>> consider
>> programming to SSPI first (or using LogonUser if possible).  If there is 
>> a
>> reason why you can't use SSPI directly (firewall only allow LDAP accesss 
>> or
>> something), the consider using the LDAP API and be very careful how you
>> handle reuse of connections (the key to scalability).  Don't use ADSI for
>> authentication if you need to scale because it won't.
>>
>> 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
>> --

Hi Joe,

It doesn't look like ADSI even allows you to specify a timeout like the LDAP 
API does.  I am currently working on a prototype for user authentication, but 
I will be porting to an LDAP API or SSPI in the near future for reasons we've 
already discussed.  For right now, I am just trying to show other teams how 
authentication against Active Directory would work from a user's perspective. 
 I've been digging through documentation on specifying a timeout via ADSI, 
but I can't find anything on the internet.  Any suggestions?

Thanks,
Alejandro





"Joe Kaplan" wrote:

> If you need to authenticate against other directories, then LDAP is usually 
> the way to go.  The only authentication method that is mentioned in the 
> actual LDAP spec is simple bind, so it is the only thing you can count on 
> for cross platform support.  Note that it is only secure when combined with 
> transport security like SSL though.
> 
> Kerberos/GSSAPI is less common outside of Windows, so I would not expect to 
> be able to use that on many other directories.  Digest is an option with 
> many other directories although you must be careful with username formats.
> 
> In general, you'll likely need to provide a variety of options and some 
> configurability if you want to have a lot of reach into other systems.
> 
> 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
> --

I don't believe you can specify a timeout, especially when doing a bind.  I 
don't actually know whether you can specify a timeout for the bind operation 
in general, but you usually establish a connection prior to that anyway 
(which is the part that is likely to time out in the first place).

Best of luck!

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
--
"cochee83"  wrote in message 
news:A2F8F6D3-7B57-4AE7-8AB4-C83B2C9F861F@microsoft.com...
> Hi Joe,
>
> It doesn't look like ADSI even allows you to specify a timeout like the 
> LDAP
> API does.  I am currently working on a prototype for user authentication, 
> but
> I will be porting to an LDAP API or SSPI in the near future for reasons 
> we've
> already discussed.  For right now, I am just trying to show other teams 
> how
> authentication against Active Directory would work from a user's 
> perspective.
> I've been digging through documentation on specifying a timeout via ADSI,
> but I can't find anything on the internet.  Any suggestions?
>
> Thanks,
> Alejandro
>
>
>
>
>
> "Joe Kaplan" wrote:
>
>> If you need to authenticate against other directories, then LDAP is 
>> usually
>> the way to go.  The only authentication method that is mentioned in the
>> actual LDAP spec is simple bind, so it is the only thing you can count on
>> for cross platform support.  Note that it is only secure when combined 
>> with
>> transport security like SSL though.
>>
>> Kerberos/GSSAPI is less common outside of Windows, so I would not expect 
>> to
>> be able to use that on many other directories.  Digest is an option with
>> many other directories although you must be careful with username 
>> formats.
>>
>> In general, you'll likely need to provide a variety of options and some
>> configurability if you want to have a lot of reach into other systems.
>>
>> 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
>> --
>

Hi,

I've defined a session user object in an *.asp file that makes a function 
call to a COM DLL (that lives in our server), which in turn makes a call to 
adsopenobject.  The first time that the user object makes the call, it works. 
 But the second time, it fails.  I was able to trace through the code and 
discovered that adsopenobject hangs the second time that it is being called.  
The only way I am able to make subsequent calls to it is when I close my 
browser, which ends up destroying the session user object.  Then I am able to 
successfully call adsopenobject.  I don't see this problem when I call 
adsopenobject using our enterprise application (non web-based).

Is there something I need to know about persistent session objects that make 
subsequent calls to adsopenobject ?

Thanks!