Ldap binding with variable OU/CN structure

[Tim Hingeley]

Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Eric Fleischman [MSFT]]

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

 

[Tim Hingeley]

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Eric Fleischman [MSFT]]

Can you provide us with a trace with the bind attempt and failure?

~Eric


--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Joe Richards [MVP]]

Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the three forms of userid


SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D joehome\joe -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


UPN Style - (e-mail address removed)

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D (e-mail address removed) -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


DN Style - cn=joe,cn=users,dc=joehome,dc=com

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D CN=joe,CN=Users,DC=joehome,DC=com -w password objectclass=*
name
version: 1
dn: dc=joehome,dc=com
name: joehome

C:\>



joe

--
Joe Richards
www.joeware.net

--

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Tim Hingeley]

Hi,

I've been using the ldap browser from www.softerra.com. It has a
search command like ldapsearch, which works fine. However, the search
commands all have the same restriction - In order to search you must
first be logged on (using the -D and -w options in ldapsearch's case).

By default AD doesn't support anonymous logins, and we don't want to
log on with any credentials other than those passed to us to
authenticate, because storing search credentials is a security risk.

What we want to do is pass a username and password to the ldap server
and have it allow us to log on irrespective of where in the hierarchy
of OU's and CN's the user account is.

Tim

Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the three forms of userid


SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D joehome\joe -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


UPN Style - (e-mail address removed)

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D (e-mail address removed) -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


DN Style - cn=joe,cn=users,dc=joehome,dc=com

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D CN=joe,CN=Users,DC=joehome,DC=com -w password objectclass=*
name
version: 1
dn: dc=joehome,dc=com
name: joehome

C:\>



joe

--
Joe Richards
www.joeware.net

--

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.


Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Eric Fleischman [MSFT]]

Joe is this related t the email you sent me earlier, or just a coincidence?

Thanks for the samples Joe, I'll tuck them away for a rainy day.
In any event, so long as you pass them properly to the server the DC should
be able to break em apart and authenticate. We handle that server side.
I typically can't show you what it should look like on the client, but with
a trace I can tell you where it is broken.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the three forms of userid


SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D joehome\joe -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


UPN Style - (e-mail address removed)

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

(e-mail address removed) -w password objectclass=* name

version: 1
dn: dc=joehome,dc=com
name: joehome


DN Style - cn=joe,cn=users,dc=joehome,dc=com

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

CN=joe,CN=Users,DC=joehome,DC=com -w password objectclass=*

name
version: 1
dn: dc=joehome,dc=com
name: joehome

C:\>



joe

--
Joe Richards
www.joeware.net

--

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.


Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Joe Richards [MVP]]

LOL. This was started that line of questions yes. Your first response actually. )

--
Joe Richards
www.joeware.net

--

Joe is this related t the email you sent me earlier, or just a coincidence?

Thanks for the samples Joe, I'll tuck them away for a rainy day.
In any event, so long as you pass them properly to the server the DC should
be able to break em apart and authenticate. We handle that server side.
I typically can't show you what it should look like on the client, but with
a trace I can tell you where it is broken.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the three forms of userid


SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D joehome\joe -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


UPN Style - (e-mail address removed)

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

(e-mail address removed) -w password objectclass=* name

version: 1
dn: dc=joehome,dc=com
name: joehome


DN Style - cn=joe,cn=users,dc=joehome,dc=com

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

CN=joe,CN=Users,DC=joehome,DC=com -w password objectclass=*

name
version: 1
dn: dc=joehome,dc=com
name: joehome

C:\>



joe

--
Joe Richards
www.joeware.net

--

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.


Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Joe Richards [MVP]]

Note that if you specify the sam name DOMAIN\USERID or the UPN (e-mail address removed) (usually but this is configurable) with
the -D and send in the password in the -w it will work. Note the examples I gave doing just that. For UPN and the SAM
Name you do not need to know anything about the hierarchy.

--
Joe Richards
www.joeware.net

--

Hi,

I've been using the ldap browser from www.softerra.com. It has a
search command like ldapsearch, which works fine. However, the search
commands all have the same restriction - In order to search you must
first be logged on (using the -D and -w options in ldapsearch's case).

By default AD doesn't support anonymous logins, and we don't want to
log on with any credentials other than those passed to us to
authenticate, because storing search credentials is a security risk.

What we want to do is pass a username and password to the ldap server
and have it allow us to log on irrespective of where in the hierarchy
of OU's and CN's the user account is.

Tim

Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the three forms of userid


SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D joehome\joe -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


UPN Style - (e-mail address removed)

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D (e-mail address removed) -w password objectclass=* name
version: 1
dn: dc=joehome,dc=com
name: joehome


DN Style - cn=joe,cn=users,dc=joehome,dc=com

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D CN=joe,CN=Users,DC=joehome,DC=com -w password objectclass=*
name
version: 1
dn: dc=joehome,dc=com
name: joehome

C:\>



joe

--
Joe Richards
www.joeware.net

--

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

There are a few properties of the user that hold when they are moved from OU
to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.


Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list every time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be logged on
to the Ldap server. We want to avoid having our ldap client log on to
the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some way so
that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.

 

[Eric Fleischman [MSFT]]

Oh ok. I was thinking that it was awfully strange if this wasn't the same.
It is a small world I guess, so nothing suprises me.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

LOL. This was started that line of questions yes. Your first response actually. )

--
Joe Richards
www.joeware.net

--

Joe is this related t the email you sent me earlier, or just a coincidence?

Thanks for the samples Joe, I'll tuck them away for a rainy day.
In any event, so long as you pass them properly to the server the DC should
be able to break em apart and authenticate. We handle that server side.
I typically can't show you what it should look like on the client, but with
a trace I can tell you where it is broken.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the

three
forms of userid

SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

joehome\joe -w
password objectclass=* name

version: 1
dn: dc=joehome,dc=com
name: joehome


UPN Style - (e-mail address removed)

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

(e-mail address removed) -w password objectclass=* name

version: 1
dn: dc=joehome,dc=com
name: joehome


DN Style - cn=joe,cn=users,dc=joehome,dc=com

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D

CN=joe,CN=Users,DC=joehome,DC=com -w password objectclass=*

name
version: 1
dn: dc=joehome,dc=com
name: joehome

C:\>



joe

--
Joe Richards
www.joeware.net

--

Sorry, no luck.

Trying to bind to the ldap server with upn=<name> or
sAMAccoutName=<name> instead of cn=<Name> returns an error "Invalid
Credentials".

Tim.

There are a few properties of the user that hold when they are

moved
from OU

to OU, so long as you dont' change them:
1) sAMAccountName
2) user principal name (UPN)

I'd try authenticating with these, and seeing if it provides what you're
looking for.

~Eric

no
rights.

Hi,

We have a java ldap client running on unix which authenticates against
an AD server. Currently, the client performs the authentication by
binding with a string such as
cn=<username>,cn=Users,dc=mycompany,dc=org

The username (and password) are supplied by a user entering them on
screen.

This is fine if all the user accounts exist in the Users container,
but they don't. There are over 10,000 accounts, and they are
structured under a hierarchy of multiple OU's.

Is there any way we can bind to the AD ldap server using a specified
username and password but without having to know where in the OU
structure they are? Something like...

cn=<username>,dc=mycompany,dc=org

One option is to specify multiple OU's and just attempt to bind to
them one after the other until one succeeds - but there are over 30
OU's and we don't want to have to keep maintaining the list

every
time

the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be

logged
on

to the Ldap server. We want to avoid having our ldap client log

on
to

the server with one set of credentials and then search for a given
user name, because the stored log on credentials represent a security
risk.

Also, allowing anonymous access to the ldap server is not a preferred
option - again for security reasons.

In the Windows world, when a user logs in to Windows they just supply
a user name and password and they are checked against the AD server
irrespective of where in the AD account hierarchy the user's account
sits. We are trying to achieve the same thing with ldap - allowing
users to authenticate without caring about the AD account hierarchy.

One option that might be acceptable is to configure AD in some

way
so

that anonymous logins are permitted but only for searching to
determine the full location of a given cn, and no other attributes -
ie a search that just verifies the existence of an account and it's
full location but no other details.