ADsOpenObject, alternative credentials, avoiding password caching
JRB
an article on binding with ADsOpenObject without success. I'm calling
ADsOpenObject with alternative credentials (not passing in NULL values
for username and password) to retrieve object information from a
domain other than the one I'm logged into.
"If alternate credentials are used, it is important to not cache the
password. Multiple bind operations can be performed by specifying the
user name and password for the first bind operation and then
specifying only the user name in subsequent binds."
I connect to the schema naming path with a username and password,
retain that connection, then attempt to connect to some other object
passing in the same username but NULL for the password. I'm
communicating with the same server. The connection attempt fails with
1326 (unknown username or bad password) but succeeds if I supply the
password. The username is in NT form i.e. domain\user.
Joe K's .NET Developer's Guide doesn't seem to cover this specific
situation when discussing connection caching on pp95-97.
Should this work? I'm logged into a W2003 server, but retrieving info
from a W2008 server in a separate forest.
TIA, John
Joe Kaplan
password, you'll get a failure.
For connection caching to work, what you are supposed to do is ensure that
you connect to the same server with the same credentials and connection
flags as your currently open connection associated with another ADSI
object/interface pointer and ADSI is SUPPOSED to use the same underlying
LDAP connection handle to perform the required operations instead of opening
a new one.
I remember once trying what the documentation you mention says and using a
null password and got the same result you did.
The only thing I'm aware of that has to do with a special behavior of using
a null password is with LDAP simple bind and empty string password. In this
case, AD logs you in remotely as the anonymous user. This behavior is
required by the LDAP V3 spec so AD supports this. However, by default
anonymous users cannot perform any operations against AD as of 2003 server
(returns operations error if you do), so AD's ability to support this part
of the spec isn't really that useful. In Win2K, anonymous operations were
allowed but usually failed due to permissions issues so the Win2K3 behavior
is probably better and is definitely more secure.
HTH!
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"JRB" <jo...@jrbsoftware.com> wrote in message
news:bc966810-cdd0-4aa1...@k13g2000prh.googlegroups.com...
Richard Mueller [MVP]
"JRB" <jo...@jrbsoftware.com> wrote in message
news:bc966810-cdd0-4aa1...@k13g2000prh.googlegroups.com...
My experience is limited. I logon to a client locally then use OpenDSObject
and alternate credentials to authenticate to the domain. Once authenticated,
I am able to bind to any other object in the domain normally. It's as if I
acquired a token for the domain with my permissions. However, it's been
awhile since I tested.
--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--
JRB
nos...@ameritech.nospam.net> wrote:
> "JRB" <j...@jrbsoftware.com> wrote in message
That may well be correct if there is only one domain involved. If I'm
logged into domain A, have mapped a drive to a server X in domain B,
then a call to ADsOpenObject to open an object on server X in domain B
with NULL values for the username and password, will result in the
domain A credentials being sent to domain B, despite already being
authenticated to domain B via the mapping. I've confirmed that with
Ethereal traces. It would be handy if there was an option to specify
which credentials to use for subsequent ADsOpenObject calls. It would
be even better if the lower layers handled this somewhat more
intelligently and figured that the request is going to server X, we
have credentials for server X, so lets use them.
Thanks for your response.
John