Ldap binding with variable OU/CN structure

  • Thread starter Thread starter Tim Hingeley
  • Start date Start date
T

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.
 
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
 
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 said:
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.


Tim Hingeley said:
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.
Click to expand...
Click to expand...
 
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.


Tim Hingeley said:
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.


Tim Hingeley said:
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.
Click to expand...
Click to expand...
Click to expand...
 
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

--

Tim Hingeley said:
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.


Tim Hingeley said:
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.
Click to expand...
Click to expand...
Click to expand...
 
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

Joe Richards said:
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

--

Tim Hingeley said:
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.
Click to expand...
Click to expand...
Click to expand...
 
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.


Joe Richards said:
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
Click to expand...
(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
Click to expand...
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.
Click to expand...
Click to expand...
Click to expand...
 
LOL. This was started that line of questions yes. Your first response actually. :o)

--
Joe Richards
www.joeware.net

--

Eric Fleischman said:
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.


Joe Richards said:
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
Click to expand...
(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
Click to expand...
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
Click to expand...
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.
Click to expand...
Click to expand...
Click to expand...
 
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

--

Tim Hingeley said:
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

Joe Richards said:
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

--

Tim Hingeley said:
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
Click to expand...
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.
Click to expand...
Click to expand...
Click to expand...
 
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.


Joe Richards said:
LOL. This was started that line of questions yes. Your first response actually. :o)

--
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.


Joe Richards said:
Don't put in upn= and samaccountname=

Here is an example of using LDAPSEARCH from the iPlanet SDK with the
Click to expand...
three
forms of userid
SAM Style - joehome\joe

C:\>ldapsearch -h w2kasdc1 -b dc=joehome,dc=com -s base -D
Click to expand...
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
Click to expand...
(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
Click to expand...
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
Click to expand...
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
Click to expand...
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
Click to expand...
every
time
the AD guys change the AD account hierarchy around.

Ldap has a search interface, but to use it you must first be
Click to expand...
logged
on
to the Ldap server. We want to avoid having our ldap client log
Click to expand...
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
Click to expand...
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.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top