ADAM: How to bind using AD account and some other newbie questions

[y2k]

Hi All,

I can't seem to find any newsgroup on here for ADAM, so hopefully nobody
will mind if I post my question under the AD newsgroup instead.

I've recently been trying out an application which requires some changes to
be made to the AD schema (an additional object class). So I decided to try
out ADAM instead on a test machine. I created an ADAM instance, imported the
user LDIF file, modified the schedule to add the additional objectClass and
also created a test "user" object.

I've not had any problems creating objects in ADAM, but now I've got a few
questions which I'm hoping somebody can help me with?

1. I can open ADAM ADSI Edit just fine using my domain account which I used
to install ADAM and create the instance. However, I cannot use it to bind to
the ADAM instance using an LDAP browser - it says invalid credentials. Why
is this? How do I bind using an AD account? Or am I supposed to use an ADAM
account? I've tried googling this but keep coming up with ADAM BIND
redirection which seems to be something to do with userProxy objects from
what I can gather?

2. I didn't set a password on my test "user" object as the ADAM user will
never have to authenticate using ADAM, ADAM will only be used to authorize
the AD user. What is best practices for an situation like this? Should I
set a password, not set a password or ... ? Or should I be using a userProxy
object instead?

3. I've tried setting up a userProxy object, but it seems that it wants the
SID from AD, but it seems to want it in HEX format. How can I get this?
I've tried using converters etc but to no avail ........

4. If I create a userProxy object in ADAM (as I understand it, a userProxy
object is almost like an extension of an AD user - it contains attributes
that could be contained in AD, but avoids the hassle and risk of modifying
the AD schema) is it possible to add additional information to the ADAM
userProxy object and then have AD look at that ADAM instance if it is queried
for information it doesn't contain.

For example, could I add Home Address to a userProxy object in an ADAM
instance, then configure AD to redirect any queries for Home Address to that
particular ADAM instance? If not, then what is the difference between an
ADAM user and an ADAM userProxy object and what is the application of an ADAM
userProxy object?

Sorry for the lengthy post, but I have googled these things but not come up
with much. So I'd really apprecaite any help anybody can give me.

Thanks in advance

[Lee Flight]

Hi

[1] ADAM distinguishes between authenticating user types on the basis
of the bind method they use. ADSIedit is doing a SASL bind for you the
windows account - SASL bind tells ADAM this is a Windows (local or domain)
account. To use a generic LDAP browser to connect to ADAM with a Windows
account the browser must support SASL bind as does e.g. ldp.exe.

[2] not sure I understand your intended usage of ADAM here but I it sounds
like you need a userProxy if you want (essentially) an ADAM "shadow" account
for your AD user.

[3] ADSIedit needs the objectSID in octet string format
0x00 0x12 0x23
the leading 0x are required add those if you cut and paste from
another ADSIedit looking at AD. You might find this thread
helpful for easier ways (ldp.exe or ldf import that handle string
SID form):

http://groups.google.co.uk/group/mic...a776f7f463485/[4] If you create a shadow account in ADAM that has extra attributesthat are not in the AD schema then you cannot get AD to "look" atthat account. You either need to modify your application to lookat both AD and ADAM or just use ADAM and sync all of the ADattributes into a userProxy object in ADAM and then populate the additionalattributes on those objects. The userProxy means that you canbind with the credentials of the AD user corresponding to the proxy if youwish. If you are not binding with the end users credentials and just wantto bind with a application specific reader account that can see all theADAM objects then you could just synchronize the AD accountsto non-bindable "user" objects in ADAM. Either way you will need some kindof sychronization tool and if you go down the userProxy route youwill need to extend the standard userProxy class to have extra attributesalong the lines of the MS-userProxyFull.ldf file.Hope that helpsLee Flight

[Lee Flight]

[4]

If you create a shadow account in ADAM that has extra attributes
that are not in the AD schema then you cannot get AD to "look" at
that account. You either need to modify your application to look
at both AD and ADAM or just use ADAM and sync all of the AD
attributes into a userProxy object in ADAM and then populate the additional
attributes on those objects. The userProxy means that you can bind with the
credentials of the AD user corresponding to the proxy if you wish.

If you are not binding with the end users credentials and just want
to bind with a application specific reader account that can see all the
ADAM objects then you could just synchronize the AD accounts
to non-bindable "user" objects in ADAM. Either way you will need some kind
of sychronization tool and if you go down the userProxy route you
will need to extend the standard userProxy class to have extra attributes
along the lines of the MS-userProxyFull.ldf file.

[y2k]

Thanks so much for the replies Lee, much appreciated. So escentially I
should be using userProxy objects by the sounds of things. I'm still
slightly confused on number 1 though. Basically, are you saying that:

If I want to bind to ADAM using an ADAM account, I use LDAP
If I want to bind to ADAM using an AD account, it uses SASL

?????

The LDAP browser I'm using is LDAPSoft LDAP Browser ... I'm guessing if it's
an LDAP browser I'm using LDAP to connect, no ? Although I'm only using the
software for testing purposes, ultimately I'll be configuring a Cisco PIX to
bind to the ADAM instance (for use with AAA) so I guess this means I need to
use an ADAM account ?

[Joe Kaplan]

> If I want to bind to ADAM using an ADAM account, I use LDAP
> If I want to bind to ADAM using an AD account, it uses SASL

Not exactly. You are always using LDAP here. The real terms you are
looking for are LDAP simple bind and LDAP SASL bind (specifically SASL with
GSS-SPNEGO mechanism).

Essentially, LDAP supports something called simple bind where the client
sends the username and password in plaintext to the server. All LDAP
servers support this because it is part of the LDAP spec. It is not secure
unless combined with SSL since plaintext credentials are used, but you can
always count on it being there.

LDAP also supports an extensibility mechanism to allow additional
authentication mechanisms to be used. This mechanism is called SASL. SASL
itself is a standard, but not all clients and servers support all SASL
mechanisms. AD and ADAM support GSS-SPNEGO (Windows Negotiate auth;
basically Kerberos or NTLM), GSS-API, DIGEST and EXTERNAL. Windows LDAP
clients (things based on wldap32) support these mechanisms as well as a few
others.

Thus, if you have Windows LDAP clients and Windows LDAP servers, you can be
sure of being able to use all of the server SASL mechanisms. If you are
using a different client, you may not. If you are using a different server,
you may have different options.

Anyway, in ADAM specifically, the GSS-SPNEGO SASL bind mechanism works
differently than other mechanisms in that it does not actually authenticate
a user in ADAM but allows ADAM to authenticate a Windows user by passing the
authentication over to the underlying operating system. This feature allows
ADAM to authenticate Windows users without having to have a bind proxy
object pointing to that user.

I hope that helps clarify a little bit.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"y2k" <[email protected]> wrote in message
news:[email protected]...
> Thanks so much for the replies Lee, much appreciated. So escentially I
> should be using userProxy objects by the sounds of things. I'm still
> slightly confused on number 1 though. Basically, are you saying that:
>
> If I want to bind to ADAM using an ADAM account, I use LDAP
> If I want to bind to ADAM using an AD account, it uses SASL
>
> ?????
>
> The LDAP browser I'm using is LDAPSoft LDAP Browser ... I'm guessing if
> it's
> an LDAP browser I'm using LDAP to connect, no ? Although I'm only using
> the
> software for testing purposes, ultimately I'll be configuring a Cisco PIX
> to
> bind to the ADAM instance (for use with AAA) so I guess this means I need
> to
> use an ADAM account ?

[Lee Flight]

Hi

read Joe's post for the mechanism.
As to what type of account you need you will need to it will depend
whether you are using AAA for Administrative account authentication
or user authorization. You need to check your cisco docs for what options
you have in those scenarios and then look at cisco platform dependencies
PIX or later ASA e.g. [1]

Lee Flight

[1]

http://www.cisco.com/en/US/docs/secu...html#wp1383395

[y2k]

Joe & Lee

Firstly, thank you so so much for your replies. I really can't thank you
enough ... while I have to admit that when I read over your reply the first
time Joe, it made no sense !! 10 reads later ... it still made no sense !!!

But after a few days of googling, reading other newsgroup replies (most of
which were either written by somebody called Joe or somebody called Lee
!!!!!) and referring back to this thread every so often, things are finally
falling into place and I understand about the different methods to bind.

I do have a few more questions though, if that's OK. Am I right in saying
that both of the following are correct?

A simple bind requires that a user object exists in ADAM. A simple bind
cannot authenticate directtly with AD
A userProxy object can be used to bind using an AD security principal. But
only simple binds are supported

I decided to export an account from AD using ldifde and then modify the
output file and re-import into ADAM as a userProxy object. The first attempt
failed saying something like WILL NOT PERFORM. Action was not permitted for
security reasons. But I think this may have been because I tried to use the
built in domain administrator account. When I exported a "regular" (still
admin) account using ldifde and re-imported using ldifde as an userProxy
object, it worked fine.

However, I was unable to authenticate using the userProxy object. I tried
running Wireshark and binding and I couldn't see any traffic going to any
domain controller. According to an MS article on ADAM bind redirection when
ADAM sees that the object type is a userProxy, it passes the authentication
over to AD ... but that doesn't seem to be happning here as far as I can see.
Any ideas why this is? Could it be because the DN of the userProxy object
has a space ? I wouldn't have thought so

Again, thank you both so much for your help. I've learned so much about
ADAM and directory services in the past week. Your help really is
appreciated so much

[y2k]

Sorry, should have mentioned ... the error when I try to bind using the
userProxy object is
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: <empty>

[Lee Flight]

Hi

inline below...

"y2k" <[email protected]> wrote in message
news:[email protected]...

> I do have a few more questions though, if that's OK. Am I right in saying
> that both of the following are correct?
>
> A simple bind requires that a user object exists in ADAM. A simple bind
> cannot authenticate directtly with AD
> A userProxy object can be used to bind using an AD security principal.
> But
> only simple binds are supported

Yes, both true.

> I decided to export an account from AD using ldifde and then modify the
> output file and re-import into ADAM as a userProxy object. The first
> attempt
> failed saying something like WILL NOT PERFORM.

That error usually means that the objectSID that you are trying to import
already exists
or that you are trying to set the objectSID for something other than a
userProxy.

> However, I was unable to authenticate using the userProxy object. I tried
> running Wireshark and binding and I couldn't see any traffic going to any
> domain controller. According to an MS article on ADAM bind redirection
> when
> ADAM sees that the object type is a userProxy, it passes the
> authentication
> over to AD ... but that doesn't seem to be happning here as far as I can
> see.
> Any ideas why this is? Could it be because the DN of the userProxy object
> has a space ? I wouldn't have thought so

By default ADAM requires [1] a secure communications channel for userProxy
binds;
these are AD passwords that need to be protected and so using a clear
channel
means that the AD password could be sniffed. To secure the channel you will
need
to set up SSL for the ADAM instance however to make progress on testing you
can disable the requirement for secure proxy bind search for
RequireSecureProxyBind
in the link below.

Lee Flight

[1]

http://technet.microsoft.com/en-us/l.../cc784622.aspx