| Author | Messages | |
achitre@xxxx.yyy
 | | 05/10/2007 2:07 AM |
| Hello,
Has anyone used LDAP Compare API for user authentication under AD? I am
trying to do something similar to what’s given here: http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
Basically, here’s the problem:
NamingEnumeration answer = context.search("cn=John Smith, ou=0001 - XYZ",
"(sn={0})", new Object[]{"Smith"}, ctls);
WORKS, but when I use ‘userPassword’ attribute to validate password,
it thows a ‘NoSuchAttribute’ exception.
NamingEnumeration answer = context.search("cn=John Smith, ou=0001 - XYZ",
"( userPassword={0})", new Object[]{"password".getBytes()},
ctls);
Any idea?
Why am I using ‘compare’ for user authentication – you ask?
Well, because my client says their AD doesn’t allow users to perform “Bind”
using InitialDirContext – that’s how their user priviledges are
setup!!! Is there another way of performing user authentication?
Thanks.
- Ajay | | | |
| dunnry
Posts:0
| | 05/10/2007 2:45 AM |
| The issue here is that the password in AD and ADAM is not kept in
cleartext. You are comparing a cleartext value of "password" against
an encrypted value. I would have to check, but it might be a binary
blob actually.
This requires you to format the password to compare into the exact
same format as the password is stored in ADAM or AD. I am not sure
what that format is going to be or if this is possible. Given the
appropriate access, I know you can set the value of the password
attribute (which gets set encrypted). However, I don't know that you
can actually ever read it back...
On 5/10/07, Ajay S. Chitre wrote:
>
>
>
>
> Hello,
>
> Has anyone used LDAP Compare API for user authentication under AD? I am
> trying to do something similar to what's given here:
> http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
>
>
>
> Basically, here's the problem:
>
> NamingEnumeration answer = context.search("cn=John Smith,
> ou=0001 - XYZ",
>
> "(sn={0})",
> new Object[]{"Smith"}, ctls);
>
> WORKS, but when I use 'userPassword' attribute to validate password, it
> thows a 'NoSuchAttribute' exception.
>
> NamingEnumeration answer = context.search("cn=John Smith,
> ou=0001 - XYZ",
>
> "(
> userPassword={0})", new Object[]{"password".getBytes()},
> ctls);
>
>
> Any idea?
>
> Why am I using 'compare' for user authentication – you ask? Well, because
> my client says their AD doesn't allow users to perform "Bind" using
> InitialDirContext – that's how their user priviledges are setup!!! Is there
> another way of performing user authentication?
>
> Thanks.
>
> - Ajay
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/10/2007 2:58 AM |
| Any chance you can use the Krb5LoginModule instead?
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
On 5/10/07, Ryan Dunn wrote:
> The issue here is that the password in AD and ADAM is not kept in
> cleartext. You are comparing a cleartext value of "password" against
> an encrypted value. I would have to check, but it might be a binary
> blob actually.
>
> This requires you to format the password to compare into the exact
> same format as the password is stored in ADAM or AD. I am not sure
> what that format is going to be or if this is possible. Given the
> appropriate access, I know you can set the value of the password
> attribute (which gets set encrypted). However, I don't know that you
> can actually ever read it back...
>
> On 5/10/07, Ajay S. Chitre wrote:
> >
> >
> >
> >
> > Hello,
> >
> > Has anyone used LDAP Compare API for user authentication under AD? I am
> > trying to do something similar to what's given here:
> > http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
> >
> >
> >
> > Basically, here's the problem:
> >
> > NamingEnumeration answer = context.search("cn=John Smith,
> > ou=0001 - XYZ",
> >
> > "(sn={0})",
> > new Object[]{"Smith"}, ctls);
> >
> > WORKS, but when I use 'userPassword' attribute to validate password, it
> > thows a 'NoSuchAttribute' exception.
> >
> > NamingEnumeration answer = context.search("cn=John Smith,
> > ou=0001 - XYZ",
> >
> > "(
> > userPassword={0})", new Object[]{"password".getBytes()},
> > ctls);
> >
> >
> > Any idea?
> >
> > Why am I using 'compare' for user authentication – you ask? Well, because
> > my client says their AD doesn't allow users to perform "Bind" using
> > InitialDirContext – that's how their user priviledges are setup!!! Is there
> > another way of performing user authentication?
> >
> > Thanks.
> >
> > - Ajay
> >
> >
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| achitre@xxxx.yyy
| | 05/10/2007 3:01 AM |
| But would this give me a 'NoSuchAttribute' Exception? From the
exception it sounds like AD doesn't even allow us to use 'userPassword'
in compare. If the problem was with the value of the password, I would
expect an empty collection returned.
-----Original Message-----
From: Ryan Dunn [mailto:dunnry@gmail.com]
Sent: Thursday, May 10, 2007 11:46 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
The issue here is that the password in AD and ADAM is not kept in
cleartext. You are comparing a cleartext value of "password" against
an encrypted value. I would have to check, but it might be a binary
blob actually.
This requires you to format the password to compare into the exact
same format as the password is stored in ADAM or AD. I am not sure
what that format is going to be or if this is possible. Given the
appropriate access, I know you can set the value of the password
attribute (which gets set encrypted). However, I don't know that you
can actually ever read it back...
On 5/10/07, Ajay S. Chitre wrote:
>
>
>
>
> Hello,
>
> Has anyone used LDAP Compare API for user authentication under AD? I
am
> trying to do something similar to what's given here:
> http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
>
>
>
> Basically, here's the problem:
>
> NamingEnumeration answer = context.search("cn=John
Smith,
> ou=0001 - XYZ",
>
> "(sn={0})",
> new Object[]{"Smith"}, ctls);
>
> WORKS, but when I use 'userPassword' attribute to validate password,
it
> thows a 'NoSuchAttribute' exception.
>
> NamingEnumeration answer = context.search("cn=John
Smith,
> ou=0001 - XYZ",
>
> "(
> userPassword={0})", new Object[]{"password".getBytes()},
> ctls);
>
>
> Any idea?
>
> Why am I using 'compare' for user authentication - you ask? Well,
because
> my client says their AD doesn't allow users to perform "Bind" using
> InitialDirContext - that's how their user priviledges are setup!!! Is
there
> another way of performing user authentication?
>
> Thanks.
>
> - Ajay
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/10/2007 3:08 AM |
| Right... I said, "Given the appropriate access, I know you can set the
value of the password
attribute (which gets set encrypted). However, I don't know that you
can actually ever read it back..."
Assuming you could even read it back, you would have to contend with
the password's formatting, which is encrypted and likely just a hash
value anyway.
In another message, I asked if you could use the Krb5LoginModule instead?
On 5/10/07, Ajay S. Chitre wrote:
> But would this give me a 'NoSuchAttribute' Exception? From the
> exception it sounds like AD doesn't even allow us to use 'userPassword'
> in compare. If the problem was with the value of the password, I would
> expect an empty collection returned.
>
> -----Original Message-----
> From: Ryan Dunn [mailto:dunnry@gmail.com]
> Sent: Thursday, May 10, 2007 11:46 AM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] LDAP Compare for user authentication...
>
> The issue here is that the password in AD and ADAM is not kept in
> cleartext. You are comparing a cleartext value of "password" against
> an encrypted value. I would have to check, but it might be a binary
> blob actually.
>
> This requires you to format the password to compare into the exact
> same format as the password is stored in ADAM or AD. I am not sure
> what that format is going to be or if this is possible. Given the
> appropriate access, I know you can set the value of the password
> attribute (which gets set encrypted). However, I don't know that you
> can actually ever read it back...
>
> On 5/10/07, Ajay S. Chitre wrote:
> >
> >
> >
> >
> > Hello,
> >
> > Has anyone used LDAP Compare API for user authentication under AD? I
> am
> > trying to do something similar to what's given here:
> > http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
> >
> >
> >
> > Basically, here's the problem:
> >
> > NamingEnumeration answer = context.search("cn=John
> Smith,
> > ou=0001 - XYZ",
> >
> > "(sn={0})",
> > new Object[]{"Smith"}, ctls);
> >
> > WORKS, but when I use 'userPassword' attribute to validate password,
> it
> > thows a 'NoSuchAttribute' exception.
> >
> > NamingEnumeration answer = context.search("cn=John
> Smith,
> > ou=0001 - XYZ",
> >
> > "(
> > userPassword={0})", new Object[]{"password".getBytes()},
> > ctls);
> >
> >
> > Any idea?
> >
> > Why am I using 'compare' for user authentication - you ask? Well,
> because
> > my client says their AD doesn't allow users to perform "Bind" using
> > InitialDirContext - that's how their user priviledges are setup!!! Is
> there
> > another way of performing user authentication?
> >
> > Thanks.
> >
> > - Ajay
> >
> >
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/10/2007 3:23 AM |
| > my client says their AD doesn't allow users to perform "Bind" using
> InitialDirContext – that's how their user priviledges are setup!!! Is there
> another way of performing user authentication?
Ajay, I got to wonder if your AD folks are feeding you some bull. I
don't even know if you can prevent a user from binding if they tried.
Perhaps someone can point me to the right ACL to set to prevent a
bind. They can certainly lock down your account and what you can see
in a directory, but to prevent binding... I don't think so. So much
other stuff would break... like logon to the domain.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| achitre@xxxx.yyy
| | 05/10/2007 3:24 AM |
| Thanks a lot for the idea, Ryan! Definitely worth exploring.
I am (pretty much) convinced that using LDAP Compare for user
authentication under AD is not a good idea... not even sure that it will
work consistently across different environments ...
Thanks again!
-----Original Message-----
From: Ryan Dunn [mailto:dunnry@gmail.com]
Sent: Thursday, May 10, 2007 11:58 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
Any chance you can use the Krb5LoginModule instead?
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/spec/com/sun/sec
urity/auth/module/Krb5LoginModule.html
On 5/10/07, Ryan Dunn wrote:
> The issue here is that the password in AD and ADAM is not kept in
> cleartext. You are comparing a cleartext value of "password" against
> an encrypted value. I would have to check, but it might be a binary
> blob actually.
>
> This requires you to format the password to compare into the exact
> same format as the password is stored in ADAM or AD. I am not sure
> what that format is going to be or if this is possible. Given the
> appropriate access, I know you can set the value of the password
> attribute (which gets set encrypted). However, I don't know that you
> can actually ever read it back...
>
> On 5/10/07, Ajay S. Chitre wrote:
> >
> >
> >
> >
> > Hello,
> >
> > Has anyone used LDAP Compare API for user authentication under AD?
I am
> > trying to do something similar to what's given here:
> > http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
> >
> >
> >
> > Basically, here's the problem:
> >
> > NamingEnumeration answer = context.search("cn=John
Smith,
> > ou=0001 - XYZ",
> >
> > "(sn={0})",
> > new Object[]{"Smith"}, ctls);
> >
> > WORKS, but when I use 'userPassword' attribute to validate
password, it
> > thows a 'NoSuchAttribute' exception.
> >
> > NamingEnumeration answer = context.search("cn=John
Smith,
> > ou=0001 - XYZ",
> >
> > "(
> > userPassword={0})", new Object[]{"password".getBytes()},
> > ctls);
> >
> >
> > Any idea?
> >
> > Why am I using 'compare' for user authentication - you ask? Well,
because
> > my client says their AD doesn't allow users to perform "Bind" using
> > InitialDirContext - that's how their user priviledges are setup!!!
Is there
> > another way of performing user authentication?
> >
> > Thanks.
> >
> > - Ajay
> >
> >
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| achitre@xxxx.yyy
| | 05/10/2007 3:30 AM |
| I knew my client was feeding me bull... Unfortunately, not being an AD
expert, I couldn't challenge them.
But you asked a good question (which I guess I should have asked them
before)... "Give me an ACL that prevents a user from binding with his
own userid & password". Let me ask that and see what they say...
-----Original Message-----
From: Ryan Dunn [mailto:dunnry@gmail.com]
Sent: Thursday, May 10, 2007 12:23 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
> my client says their AD doesn't allow users to perform "Bind" using
> InitialDirContext - that's how their user priviledges are setup!!! Is
there
> another way of performing user authentication?
Ajay, I got to wonder if your AD folks are feeding you some bull. I
don't even know if you can prevent a user from binding if they tried.
Perhaps someone can point me to the right ACL to set to prevent a
bind. They can certainly lock down your account and what you can see
in a directory, but to prevent binding... I don't think so. So much
other stuff would break... like logon to the domain.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/10/2007 3:43 AM |
| Before you ask them... just prove it to yourself. Take a username and
password you know on the domain and bind using ldp.exe.
On 5/10/07, Ajay S. Chitre wrote:
> I knew my client was feeding me bull... Unfortunately, not being an AD
> expert, I couldn't challenge them.
>
> But you asked a good question (which I guess I should have asked them
> before)... "Give me an ACL that prevents a user from binding with his
> own userid & password". Let me ask that and see what they say...
>
>
> -----Original Message-----
> From: Ryan Dunn [mailto:dunnry@gmail.com]
> Sent: Thursday, May 10, 2007 12:23 PM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] LDAP Compare for user authentication...
>
> > my client says their AD doesn't allow users to perform "Bind" using
> > InitialDirContext - that's how their user priviledges are setup!!! Is
> there
> > another way of performing user authentication?
>
> Ajay, I got to wonder if your AD folks are feeding you some bull. I
> don't even know if you can prevent a user from binding if they tried.
> Perhaps someone can point me to the right ACL to set to prevent a
> bind. They can certainly lock down your account and what you can see
> in a directory, but to prevent binding... I don't think so. So much
> other stuff would break... like logon to the domain.
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| MThommes
Posts:106
| | 05/10/2007 4:01 AM |
| Does this help the discussion at all?
http://www.petri.co.il/anonymous_ldap_operations_in_windows_2003_ad.htm
Mike thommes
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ryan Dunn
Sent: Thursday, May 10, 2007 2:43 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
Before you ask them... just prove it to yourself. Take a username and
password you know on the domain and bind using ldp.exe.
On 5/10/07, Ajay S. Chitre wrote:
> I knew my client was feeding me bull... Unfortunately, not being an AD
> expert, I couldn't challenge them.
>
> But you asked a good question (which I guess I should have asked them
> before)... "Give me an ACL that prevents a user from binding with his
> own userid & password". Let me ask that and see what they say...
>
>
> -----Original Message-----
> From: Ryan Dunn [mailto:dunnry@gmail.com]
> Sent: Thursday, May 10, 2007 12:23 PM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] LDAP Compare for user authentication...
>
> > my client says their AD doesn't allow users to perform "Bind" using
> > InitialDirContext - that's how their user priviledges are setup!!!
Is
> there
> > another way of performing user authentication?
>
> Ajay, I got to wonder if your AD folks are feeding you some bull. I
> don't even know if you can prevent a user from binding if they tried.
> Perhaps someone can point me to the right ACL to set to prevent a
> bind. They can certainly lock down your account and what you can see
> in a directory, but to prevent binding... I don't think so. So much
> other stuff would break... like logon to the domain.
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| amulnick
Posts:163
| | 05/10/2007 4:55 AM |
| Right. That's likely what they're talking about when they say you don't have the rights. It's not that you don't have the rights, it's that you don't have the ability.
It's fairly common to bind using Java for applications via ldap and sometimes even over ssl. As you read that link below, you'll have to pay attention to the trade-offs you'd be asking your customer to make in order to do ldap bind for your authentication (I shudder when I put ldap and authentication in the same sentence...)
You will NOT be able to compare the password. Well, it may be possible, but again, not by default. (reversible encryption is there for a reason, although I have yet to see anyone use it; it MAY allow you to do what you talk about although I'd think less of you if you did that :)
Think about that approach you are currently approaching (note:I'm not a developer of Java apps)for a second. If you could read the password prior to being authenticated, wouldn't that be a problem?
After you read the docs Michael posted the link for, check out the information that Ryan earlier posted about kerberos and java. Might be a much better path to take.
Al
On 5/10/07, Thommes, Michael M. wrote:
Does this help the discussion at all?
http://www.petri.co.il/anonymous_ldap_operations_in_windows_2003_ad.htmMike thommes-----Original Message-----From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ryan DunnSent: Thursday, May 10, 2007 2:43 PMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] LDAP Compare for user authentication...Before you ask them... just prove it to yourself.Take a username andpassword you know on the domain and bind using
ldp.exe.On 5/10/07, Ajay S. Chitre wrote:> I knew my client was feeding me bull... Unfortunately, not being an AD> expert, I couldn't challenge them.
>> But you asked a good question (which I guess I should have asked them> before)... "Give me an ACL that prevents a user from binding with his> own userid & password".Let me ask that and see what they say...
>>> -----Original Message-----> From: Ryan Dunn [mailto:dunnry@gmail.com]> Sent: Thursday, May 10, 2007 12:23 PM> To:
ActiveDir@mail.activedir.org> Subject: Re: [ActiveDir] LDAP Compare for user authentication...>> > my client says their AD doesn't allow users to perform "Bind" using> > InitialDirContext - that's how their user priviledges are setup!!!
Is> there> > another way of performing user authentication?>> Ajay, I got to wonder if your AD folks are feeding you some bull.I> don't even know if you can prevent a user from binding if they tried.
> Perhaps someone can point me to the right ACL to set to prevent a> bind.They can certainly lock down your account and what you can see> in a directory, but to prevent binding... I don't think so.So much
> other stuff would break... like logon to the domain.> List info : http://www.activedir.org/List.aspx> List FAQ:
http://www.activedir.org/ListFAQ.aspx> List archive: http://www.activedir.org/ma/default.aspx> List info :
http://www.activedir.org/List.aspx> List FAQ: http://www.activedir.org/ListFAQ.aspx> List archive:
http://www.activedir.org/ma/default.aspx>List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspxList info : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ma/default.aspx | | | |
| achitre@xxxx.yyy
| | 05/10/2007 5:05 AM |
| >> Think about that
approach you are currently approaching (note:I'm not a developer of Java
apps)for a second. If you could read the password prior to being
authenticated, wouldn't that be a problem?
The following article from Sun says… “Some servers might use this
feature for passwords……”. That’s why we decided
to explore it!
http://java.sun.com/products/jndi/tutorial/ldap/search/compare.html
Note: We don’t really *read* the password… as the article points out…
” This allows the server to keep certain attribute/value pairs secret
(i.e., not exposed for general "search" access) while still allowing
the client limited use of them……”
-----Original Message-----
From: Al Mulnick
[mailto:amulnick@gmail.com]
Sent: Thursday, May 10, 2007 1:55
PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP
Compare for user authentication...
Right. That's likely what they're talking about
when they say you don't have the rights. It's not that you don't have the
rights, it's that you don't have the ability.
It's fairly common to bind using Java for applications
via ldap and sometimes even over ssl. As you read that link below, you'll
have to pay attention to the trade-offs you'd be asking your customer to make
in order to do ldap bind for your authentication (I shudder when I put ldap and
authentication in the same sentence...)
You will NOT be able to compare the password.
Well, it may be possible, but again, not by default. (reversible encryption is
there for a reason, although I have yet to see anyone use it; it MAY allow you
to do what you talk about although I'd think less of you if you did that
:)
Think about that approach you are currently
approaching (note:I'm not a developer of Java apps)for a second. If you
could read the password prior to being authenticated, wouldn't that be a
problem?
After you read the docs Michael posted the link for,
check out the information that Ryan earlier posted about kerberos and java.
Might be a much better path to take.
Al
On 5/10/07, Thommes, Michael M. wrote:
Does this help the discussion at all?
http://www.petri.co.il/anonymous_ldap_operations_in_windows_2003_ad.htm
Mike thommes
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Ryan Dunn
Sent: Thursday, May 10, 2007 2:43 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
Before you ask them... just prove it to yourself.Take a username
and
password you know on the domain and bind using ldp.exe.
On 5/10/07, Ajay S. Chitre
wrote:
> I knew my client was feeding me bull... Unfortunately, not being an AD
> expert, I couldn't challenge them.
>
> But you asked a good question (which I guess I should have asked them
> before)... "Give me an ACL that prevents a user from binding with his
> own userid & password".Let me ask that and see what
they say...
>
>
> -----Original Message-----
> From: Ryan Dunn [mailto:dunnry@gmail.com]
> Sent: Thursday, May 10, 2007 12:23 PM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] LDAP Compare for user authentication...
>
> > my client says their AD doesn't allow users to perform
"Bind" using
> > InitialDirContext - that's how their user priviledges are setup!!!
Is
> there
> > another way of performing user authentication?
>
> Ajay, I got to wonder if your AD folks are feeding you some
bull.I
> don't even know if you can prevent a user from binding if they tried.
> Perhaps someone can point me to the right ACL to set to prevent a
> bind.They can certainly lock down your account and what you
can see
> in a directory, but to prevent binding... I don't think so.So
much
> other stuff would break... like logon to the domain.
> List info : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
List info : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/10/2007 5:14 AM |
| > Right. That's likely what they're talking about when they say you don't
> have the rights. It's not that you don't have the rights, it's that you
> don't have the ability.
I have no doubt that anonymous binds are not allowed. However, I
doubt that authenticated binds are disabled - lots of stuff wouldn't
work IMO. I might be wrong... but like I said, just bind with ldp.exe
and you will know if I am wrong or not. Note, I am talking about
just binding here, no other operations (i.e. just changing the
connection state to authenticated).
> It's fairly common to bind using Java for applications via ldap and
> sometimes even over ssl. As you read that link below, you'll have to pay
> attention to the trade-offs you'd be asking your customer to make in order
> to do ldap bind for your authentication (I shudder when I put ldap and
> authentication in the same sentence...)
>
For high volume apps, yes, I agree that LDAP bind might be a bit too
heavy. For smallish apps, this won't hurt too bad. If you have a
truly high-volume app, you should look into Fast Concurrent Binding
with Windows 2003.
> You will NOT be able to compare the password. Well, it may be possible, but
> again, not by default. (reversible encryption is there for a reason,
> although I have yet to see anyone use it; it MAY allow you to do what you
> talk about although I'd think less of you if you did that :)
Reversible encryption I know is used with Digest Authentication. I
have not seen it used much else. Even if the password is reversible
encryption, I am not sure you can read the attribute in AD - I still
think it is write-only here.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| listmail
Posts:822
| | 05/10/2007 7:41 AM |
| @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
page: Section1
}
Java isn't floating up a complete error for you. Any time
working with AD and/or ADAMand you run into issues you should be looking
for the extended error info. Either through the program or if the program
doesn't float that info up, via network trace or duplicating the operation
through another tool that does give that info. Would be nice if you could turn
on LDAP Client tracing via the OS and have that info just dumped into the event
log but that would also depend on the client using the Windows LDAP libs and
Java almost certainly isn't. They would use something else just for spite even
if it makes life tougher. :)
So you can do this through LDP, set up the compare and you
get the full error message of
Error: ldap_compare(): No Such Attribute.
<16>Server error: 00002080: AtrErr: DSID-03080139, #1:0:
00002080: DSID-03080139, problem 1001 (NO_ATTRIBUTE_OR_VAL), data 0, Att 23
(userPassword)
Error 2080 is
F:\Dev\_EXPLOITS\DNSRPC>err 2080# for hex 0x2080 /
decimal 8320 :
ERROR_DS_CANT_ADD_ATT_VALUES
winerror.h# The specified attribute is not present, or has no values.# 1
matches found for "2080"
which, voila, explains it perfectly...The
specified attribute is not present, or has no
values.
You cannot read the password attributes, period.
Whetherreversibly encrypted or not. You cannot see a password, you cannot
see a hash, you cannot see a blob, nothing.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ajay S.
ChitreSent: Thursday, May 10, 2007 2:07 PMTo:
ActiveDir@mail.activedir.orgSubject: [ActiveDir] LDAP Compare for
user authentication...
Hello,Has anyone used LDAP
Compare API for user authentication under AD? I am trying to do something
similar to what’s given here: http://java.sun.com/products/jndi/tutorial/ldap/search/compare.htmlBasically,
here’s the
problem:
NamingEnumeration answer = context.search("cn=John Smith, ou=0001 -
XYZ",
"(sn={0})", new Object[]{"Smith"}, ctls);WORKS, but when I use
‘userPassword’ attribute to validate password, it thows a ‘NoSuchAttribute’
exception.
NamingEnumeration answer = context.search("cn=John Smith, ou=0001 -
XYZ",
"( userPassword={0})", new
Object[]{"password".getBytes()}, ctls);Any idea? Why
am I using ‘compare’ for user authentication – you ask? Well, because my
client says their AD doesn’t allow users to perform “Bind” using
InitialDirContext – that’s how their user priviledges are setup!!! Is
there another way of performing user authentication?Thanks.-
Ajay | | | |
| amulnick
Posts:163
| | 05/11/2007 9:22 AM |
| For high volume apps, yes, I agree that LDAP bind might be a bit tooheavy. For smallish apps, this won't hurt too bad. If you have atruly high-volume app, you should look into Fast Concurrent Binding
with Windows 2003.
You misunderstood my thoughts there. Let me try again.
I was being purposefuly vague about the issues. But I have not always been that vague.
LDAP != authentication protocol. Although sometimes seen in the wild posing as an authentication protocol, it's not. It's not a server. It's a lightweight version of DAP. It's used to access a directory. Authentication is somebody else's job.
Asking your customer to go down this route is something I never recommend. It may scale (Sun seems to make it work in some cases) but it's designed for authentication. It has shortcomings that may become difficult to live with.
Just in case there were any misunderstandings.
-ajm
On 5/10/07, Ryan Dunn wrote:
> Right.That's likely what they're talking about when they say you don't> have the rights.It's not that you don't have the rights, it's that you
> don't have the ability.I have no doubt that anonymous binds are not allowed.However, Idoubt that authenticated binds are disabled - lots of stuff wouldn'twork IMO.I might be wrong... but like I said, just bind with
ldp.exeand you will know if I am wrong or not. Note, I am talking aboutjust binding here, no other operations (i.e. just changing theconnection state to authenticated).> It's fairly common to bind using Java for applications via ldap and
> sometimes even over ssl.As you read that link below, you'll have to pay> attention to the trade-offs you'd be asking your customer to make in order> to do ldap bind for your authentication (I shudder when I put ldap and
> authentication in the same sentence...)>For high volume apps, yes, I agree that LDAP bind might be a bit tooheavy.For smallish apps, this won't hurt too bad.If you have atruly high-volume app, you should look into Fast Concurrent Binding
with Windows 2003.> You will NOT be able to compare the password.Well, it may be possible, but> again, not by default. (reversible encryption is there for a reason,> although I have yet to see anyone use it; it MAY allow you to do what you
> talk about although I'd think less of you if you did that :)Reversible encryption I know is used with Digest Authentication.Ihave not seen it used much else.Even if the password is reversible
encryption, I am not sure you can read the attribute in AD - I stillthink it is write-only here.List info : http://www.activedir.org/List.aspxList FAQ:
http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ma/default.aspx | | | |
| AD000001730
Posts:0
| | 05/12/2007 1:09 AM |
| If you're getting a TGT every time it, then yes it will definitely be
slower. But in an Intranet environement getting/renewing a TGT only
happends once every 10 hours for a given logon session. So I don't
fully understand how you cannot attribute ticket caching to the overall
performance of the application. If a client is logged into the domain
and there are no reverse proxies or whatever in the way and they have
visited the application in the last 10 hours, subsequent authentications
with that application will require no communication with the DC at all.
Mike
On Sat, 12 May 2007 12:33:41 -0400
"joe" wrote:
> This assumes kerberized clients doing the auth prior to talking to the app
> server in which case the auth isn't faster but is distributed so couldn't
> really be measured as part of the app speed. The domain auth is part of the
> TGT process and the app server would only be involved in the TGS process
> which means the client is already auth'ed. This may or may not be an
> assumption you can make, on an internal network where the client pool is
> completely controlled or you just refuse any clients that don't come
> knocking with a kerb cert, you probably can make this assumption. In larger
> environments it gets tough to assume this as you could have multiple
> untrusted forests, people using machines that aren't joined to any domain
> (this is my standard running method), folks coming in through various
> reverse proxies, etc.
>
> Straight Kerberos auth up against the FCB is going to be slower as it has
> more work to do; including updating the logon time. I think what you were
> referring to when you mention that logon time isn't updated with Kerb auth
> is that it isn't updated for TGS requests. Certainly the TGT request pops it
> or else the attribute would have no value unless you did a lot of NTLM auth.
>
> joe
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Michael B Allen
> Sent: Saturday, May 12, 2007 12:16 PM
> To: ActiveDir@mail.activedir.org
> Cc: Ryan Dunn
> Subject: Re: [ActiveDir] LDAP Compare for user authentication...
>
> Kerberos auth does not require any communication between the application
> server and the domain controller. The fully expanded groups are in
> the PAC in the ticket and the logon time is not updated for a kerberos
> auth. So if the app server is on a different host from the DC, then in
> theory Kerberos should actually, in theory, be *faster* because FCB would
> require network communication with the DC whereas Kerberos does not at
> all. FCB multiplexes binds over the same transport but it's still gotta
> send out electrons over a wire.
>
> So I'm a little shocked to hear your results but I've never tried the
> scenario you describe so ...
>
> Mike
>
>
> On Sat, 12 May 2007 01:49:24 -0700
> "Ryan Dunn" wrote:
>
> > Just noticed that this did not reply to the group:
> >
> > I was of the same opinion until one of my co-workers asked for my help
> > to use FCB on a very large installation. We also tested both
> > LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
> > unmanaged implementations. We found that using FCB was both faster
> > and less resource intensive (CPU mainly) and scaled the best. I don't
> > have the exact numbers anymore, but it was very large and very
> > demanding.
> >
> > I think they were going for using LDAP as authentication with FCB, and
> > they did one heck of a job. You don't have to believe me. Just try
> > it with large client loads.
> >
> > Also, I am not including building authorization into this either -
> > this is purely authentication. If you are looking to build a Windows
> > Security token, this is not the way to do it. You can approximate it
> > if your application understands IPrincipal, but it is not a
> > replacement for full Windows authorization.
> >
> > On 5/11/07, Michael B Allen wrote:
> > > On Fri, 11 May 2007 22:37:58 -0700
> > > "Ryan Dunn" wrote:
> > >
> > > > I agree with you... with one fairly large caveat. FCB is an excellent
> > > > auth method and in my testing is faster than SSPI, LogonUser, or any
> > > > other authentication method. In fact, this is what is used with the
> > > > ActiveDirectoryMembershipProvider for authentication when SSL is
> > > > available.
> > > >
> > > > For normal LDAP bind, LDAP != Authentication (assuming other
> > > > authentication methods are not available). I agree. For FCB LDAP
> > > > bind == Authentication however.
> > >
> > > Out of curiosity I just looked up FCB so I may not be fully informed
> > > but I don't think I would characterize it as an "excellent auth
> > > method". Kerberos would be just as fast (faster in a cross domain
> > > scenario) and you get a real binding, a security token and a session
> key.
> > >
> > > FCB sounds like it's just trying to accomodate the many existing
> > > applications that use LDAP as a make-shift authentication service.
> > >
> > > Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> > > I think the argument for using LDAP for auth will become less
> compelling.
> > >
> > > Mike
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/12/2007 1:37 AM |
| I agree with you... with one fairly large caveat. FCB is an excellent
auth method and in my testing is faster than SSPI, LogonUser, or any
other authentication method. In fact, this is what is used with the
ActiveDirectoryMembershipProvider for authentication when SSL is
available.
For normal LDAP bind, LDAP != Authentication (assuming other
authentication methods are not available). I agree. For FCB LDAP
bind == Authentication however.
On 5/11/07, Al Mulnick wrote:
> For high volume apps, yes, I agree that LDAP bind might be a bit too
> heavy. For smallish apps, this won't hurt too bad. If you have a
> truly high-volume app, you should look into Fast Concurrent Binding
> with Windows 2003.
>
> You misunderstood my thoughts there. Let me try again.
> I was being purposefuly vague about the issues. But I have not always been
> that vague.
>
> LDAP != authentication protocol. Although sometimes seen in the wild posing
> as an authentication protocol, it's not. It's not a server. It's a
> lightweight version of DAP. It's used to access a directory.
> Authentication is somebody else's job.
>
> Asking your customer to go down this route is something I never recommend.
> It may scale (Sun seems to make it work in some cases) but it's designed for
> authentication. It has shortcomings that may become difficult to live with.
>
>
> Just in case there were any misunderstandings.
>
> -ajm
>
>
> On 5/10/07, Ryan Dunn wrote:
> >
> > > Right. That's likely what they're talking about when they say you don't
> > > have the rights. It's not that you don't have the rights, it's that you
> > > don't have the ability.
> >
> > I have no doubt that anonymous binds are not allowed. However, I
> > doubt that authenticated binds are disabled - lots of stuff wouldn't
> > work IMO. I might be wrong... but like I said, just bind with ldp.exe
> > and you will know if I am wrong or not. Note, I am talking about
> > just binding here, no other operations (i.e. just changing the
> > connection state to authenticated).
> >
> > > It's fairly common to bind using Java for applications via ldap and
> > > sometimes even over ssl. As you read that link below, you'll have to
> pay
> > > attention to the trade-offs you'd be asking your customer to make in
> order
> > > to do ldap bind for your authentication (I shudder when I put ldap and
> > > authentication in the same sentence...)
> > >
> > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > heavy. For smallish apps, this won't hurt too bad. If you have a
> > truly high-volume app, you should look into Fast Concurrent Binding
> > with Windows 2003.
> >
> > > You will NOT be able to compare the password. Well, it may be possible,
> but
> > > again, not by default. (reversible encryption is there for a reason,
> > > although I have yet to see anyone use it; it MAY allow you to do what
> you
> > > talk about although I'd think less of you if you did that :)
> >
> > Reversible encryption I know is used with Digest Authentication. I
> > have not seen it used much else. Even if the password is reversible
> > encryption, I am not sure you can read the attribute in AD - I still
> > think it is write-only here.
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
> >
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| AD000001730
Posts:0
| | 05/12/2007 2:50 AM |
| On Fri, 11 May 2007 22:37:58 -0700
"Ryan Dunn" wrote:
> I agree with you... with one fairly large caveat. FCB is an excellent
> auth method and in my testing is faster than SSPI, LogonUser, or any
> other authentication method. In fact, this is what is used with the
> ActiveDirectoryMembershipProvider for authentication when SSL is
> available.
>
> For normal LDAP bind, LDAP != Authentication (assuming other
> authentication methods are not available). I agree. For FCB LDAP
> bind == Authentication however.
Out of curiosity I just looked up FCB so I may not be fully informed
but I don't think I would characterize it as an "excellent auth
method". Kerberos would be just as fast (faster in a cross domain
scenario) and you get a real binding, a security token and a session key.
FCB sounds like it's just trying to accomodate the many existing
applications that use LDAP as a make-shift authentication service.
Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
I think the argument for using LDAP for auth will become less compelling.
Mike
> On 5/11/07, Al Mulnick wrote:
> > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > heavy. For smallish apps, this won't hurt too bad. If you have a
> > truly high-volume app, you should look into Fast Concurrent Binding
> > with Windows 2003.
> >
> > You misunderstood my thoughts there. Let me try again.
> > I was being purposefuly vague about the issues. But I have not always been
> > that vague.
> >
> > LDAP != authentication protocol. Although sometimes seen in the wild posing
> > as an authentication protocol, it's not. It's not a server. It's a
> > lightweight version of DAP. It's used to access a directory.
> > Authentication is somebody else's job.
> >
> > Asking your customer to go down this route is something I never recommend.
> > It may scale (Sun seems to make it work in some cases) but it's designed for
> > authentication. It has shortcomings that may become difficult to live with.
> >
> >
> > Just in case there were any misunderstandings.
> >
> > -ajm
> >
> >
> > On 5/10/07, Ryan Dunn wrote:
> > >
> > > > Right. That's likely what they're talking about when they say you don't
> > > > have the rights. It's not that you don't have the rights, it's that you
> > > > don't have the ability.
> > >
> > > I have no doubt that anonymous binds are not allowed. However, I
> > > doubt that authenticated binds are disabled - lots of stuff wouldn't
> > > work IMO. I might be wrong... but like I said, just bind with ldp.exe
> > > and you will know if I am wrong or not. Note, I am talking about
> > > just binding here, no other operations (i.e. just changing the
> > > connection state to authenticated).
> > >
> > > > It's fairly common to bind using Java for applications via ldap and
> > > > sometimes even over ssl. As you read that link below, you'll have to
> > pay
> > > > attention to the trade-offs you'd be asking your customer to make in
> > order
> > > > to do ldap bind for your authentication (I shudder when I put ldap and
> > > > authentication in the same sentence...)
> > > >
> > > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > > heavy. For smallish apps, this won't hurt too bad. If you have a
> > > truly high-volume app, you should look into Fast Concurrent Binding
> > > with Windows 2003.
> > >
> > > > You will NOT be able to compare the password. Well, it may be possible,
> > but
> > > > again, not by default. (reversible encryption is there for a reason,
> > > > although I have yet to see anyone use it; it MAY allow you to do what
> > you
> > > > talk about although I'd think less of you if you did that :)
> > >
> > > Reversible encryption I know is used with Digest Authentication. I
> > > have not seen it used much else. Even if the password is reversible
> > > encryption, I am not sure you can read the attribute in AD - I still
> > > think it is write-only here.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| dunnry
Posts:0
| | 05/12/2007 4:49 AM |
| Just noticed that this did not reply to the group:
I was of the same opinion until one of my co-workers asked for my help
to use FCB on a very large installation. We also tested both
LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
unmanaged implementations. We found that using FCB was both faster
and less resource intensive (CPU mainly) and scaled the best. I don't
have the exact numbers anymore, but it was very large and very
demanding.
I think they were going for using LDAP as authentication with FCB, and
they did one heck of a job. You don't have to believe me. Just try
it with large client loads.
Also, I am not including building authorization into this either -
this is purely authentication. If you are looking to build a Windows
Security token, this is not the way to do it. You can approximate it
if your application understands IPrincipal, but it is not a
replacement for full Windows authorization.
On 5/11/07, Michael B Allen wrote:
> On Fri, 11 May 2007 22:37:58 -0700
> "Ryan Dunn" wrote:
>
> > I agree with you... with one fairly large caveat. FCB is an excellent
> > auth method and in my testing is faster than SSPI, LogonUser, or any
> > other authentication method. In fact, this is what is used with the
> > ActiveDirectoryMembershipProvider for authentication when SSL is
> > available.
> >
> > For normal LDAP bind, LDAP != Authentication (assuming other
> > authentication methods are not available). I agree. For FCB LDAP
> > bind == Authentication however.
>
> Out of curiosity I just looked up FCB so I may not be fully informed
> but I don't think I would characterize it as an "excellent auth
> method". Kerberos would be just as fast (faster in a cross domain
> scenario) and you get a real binding, a security token and a session key.
>
> FCB sounds like it's just trying to accomodate the many existing
> applications that use LDAP as a make-shift authentication service.
>
> Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> I think the argument for using LDAP for auth will become less compelling.
>
> Mike
>
> > On 5/11/07, Al Mulnick wrote:
> > > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > > heavy. For smallish apps, this won't hurt too bad. If you have a
> > > truly high-volume app, you should look into Fast Concurrent Binding
> > > with Windows 2003.
> > >
> > > You misunderstood my thoughts there. Let me try again.
> > > I was being purposefuly vague about the issues. But I have not always been
> > > that vague.
> > >
> > > LDAP != authentication protocol. Although sometimes seen in the wild posing
> > > as an authentication protocol, it's not. It's not a server. It's a
> > > lightweight version of DAP. It's used to access a directory.
> > > Authentication is somebody else's job.
> > >
> > > Asking your customer to go down this route is something I never recommend.
> > > It may scale (Sun seems to make it work in some cases) but it's designed for
> > > authentication. It has shortcomings that may become difficult to live with.
> > >
> > >
> > > Just in case there were any misunderstandings.
> > >
> > > -ajm
> > >
> > >
> > > On 5/10/07, Ryan Dunn wrote:
> > > >
> > > > > Right. That's likely what they're talking about when they say you don't
> > > > > have the rights. It's not that you don't have the rights, it's that you
> > > > > don't have the ability.
> > > >
> > > > I have no doubt that anonymous binds are not allowed. However, I
> > > > doubt that authenticated binds are disabled - lots of stuff wouldn't
> > > > work IMO. I might be wrong... but like I said, just bind with ldp.exe
> > > > and you will know if I am wrong or not. Note, I am talking about
> > > > just binding here, no other operations (i.e. just changing the
> > > > connection state to authenticated).
> > > >
> > > > > It's fairly common to bind using Java for applications via ldap and
> > > > > sometimes even over ssl. As you read that link below, you'll have to
> > > pay
> > > > > attention to the trade-offs you'd be asking your customer to make in
> > > order
> > > > > to do ldap bind for your authentication (I shudder when I put ldap and
> > > > > authentication in the same sentence...)
> > > > >
> > > > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > > > heavy. For smallish apps, this won't hurt too bad. If you have a
> > > > truly high-volume app, you should look into Fast Concurrent Binding
> > > > with Windows 2003.
> > > >
> > > > > You will NOT be able to compare the password. Well, it may be possible,
> > > but
> > > > > again, not by default. (reversible encryption is there for a reason,
> > > > > although I have yet to see anyone use it; it MAY allow you to do what
> > > you
> > > > > talk about although I'd think less of you if you did that :)
> > > >
> > > > Reversible encryption I know is used with Digest Authentication. I
> > > > have not seen it used much else. Even if the password is reversible
> > > > encryption, I am not sure you can read the attribute in AD - I still
> > > > think it is write-only here.
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| listmail
Posts:822
| | 05/12/2007 7:33 AM |
| Correct, we are saying the same thing.
Where we deviate is that you assume being in an intranet environment, the
client is automatically and definitely going to be able to get the TGT and
TGS and I am saying that isn't an assumption you can make unless you are
doing something to enforce it. Most large environments do not have all
machines in the same trusted forest even if they would really really like
to. Even the ones that tell you do I have been pretty lucky at finding good
numbers of machines that aren't.
But yes, if all clients are kerberized and trusted, the auth is all handled
in a distributed fashion and the app will not experience any overhead due to
it.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: Michael B Allen [mailto:mba2000@ioplex.com]
Sent: Saturday, May 12, 2007 1:10 PM
To: ActiveDir@mail.activedir.org
Cc: joe
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
If you're getting a TGT every time it, then yes it will definitely be
slower. But in an Intranet environement getting/renewing a TGT only
happends once every 10 hours for a given logon session. So I don't
fully understand how you cannot attribute ticket caching to the overall
performance of the application. If a client is logged into the domain
and there are no reverse proxies or whatever in the way and they have
visited the application in the last 10 hours, subsequent authentications
with that application will require no communication with the DC at all.
Mike
On Sat, 12 May 2007 12:33:41 -0400
"joe" wrote:
> This assumes kerberized clients doing the auth prior to talking to the app
> server in which case the auth isn't faster but is distributed so couldn't
> really be measured as part of the app speed. The domain auth is part of
the
> TGT process and the app server would only be involved in the TGS process
> which means the client is already auth'ed. This may or may not be an
> assumption you can make, on an internal network where the client pool is
> completely controlled or you just refuse any clients that don't come
> knocking with a kerb cert, you probably can make this assumption. In
larger
> environments it gets tough to assume this as you could have multiple
> untrusted forests, people using machines that aren't joined to any domain
> (this is my standard running method), folks coming in through various
> reverse proxies, etc.
>
> Straight Kerberos auth up against the FCB is going to be slower as it has
> more work to do; including updating the logon time. I think what you were
> referring to when you mention that logon time isn't updated with Kerb auth
> is that it isn't updated for TGS requests. Certainly the TGT request pops
it
> or else the attribute would have no value unless you did a lot of NTLM
auth.
>
> joe
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Michael B Allen
> Sent: Saturday, May 12, 2007 12:16 PM
> To: ActiveDir@mail.activedir.org
> Cc: Ryan Dunn
> Subject: Re: [ActiveDir] LDAP Compare for user authentication...
>
> Kerberos auth does not require any communication between the application
> server and the domain controller. The fully expanded groups are in
> the PAC in the ticket and the logon time is not updated for a kerberos
> auth. So if the app server is on a different host from the DC, then in
> theory Kerberos should actually, in theory, be *faster* because FCB would
> require network communication with the DC whereas Kerberos does not at
> all. FCB multiplexes binds over the same transport but it's still gotta
> send out electrons over a wire.
>
> So I'm a little shocked to hear your results but I've never tried the
> scenario you describe so ...
>
> Mike
>
>
> On Sat, 12 May 2007 01:49:24 -0700
> "Ryan Dunn" wrote:
>
> > Just noticed that this did not reply to the group:
> >
> > I was of the same opinion until one of my co-workers asked for my help
> > to use FCB on a very large installation. We also tested both
> > LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
> > unmanaged implementations. We found that using FCB was both faster
> > and less resource intensive (CPU mainly) and scaled the best. I don't
> > have the exact numbers anymore, but it was very large and very
> > demanding.
> >
> > I think they were going for using LDAP as authentication with FCB, and
> > they did one heck of a job. You don't have to believe me. Just try
> > it with large client loads.
> >
> > Also, I am not including building authorization into this either -
> > this is purely authentication. If you are looking to build a Windows
> > Security token, this is not the way to do it. You can approximate it
> > if your application understands IPrincipal, but it is not a
> > replacement for full Windows authorization.
> >
> > On 5/11/07, Michael B Allen wrote:
> > > On Fri, 11 May 2007 22:37:58 -0700
> > > "Ryan Dunn" wrote:
> > >
> > > > I agree with you... with one fairly large caveat. FCB is an
excellent
> > > > auth method and in my testing is faster than SSPI, LogonUser, or any
> > > > other authentication method. In fact, this is what is used with the
> > > > ActiveDirectoryMembershipProvider for authentication when SSL is
> > > > available.
> > > >
> > > > For normal LDAP bind, LDAP != Authentication (assuming other
> > > > authentication methods are not available). I agree. For FCB LDAP
> > > > bind == Authentication however.
> > >
> > > Out of curiosity I just looked up FCB so I may not be fully informed
> > > but I don't think I would characterize it as an "excellent auth
> > > method". Kerberos would be just as fast (faster in a cross domain
> > > scenario) and you get a real binding, a security token and a session
> key.
> > >
> > > FCB sounds like it's just trying to accomodate the many existing
> > > applications that use LDAP as a make-shift authentication service.
> > >
> > > Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> > > I think the argument for using LDAP for auth will become less
> compelling.
> > >
> > > Mike
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
|
|