>>and second I don't particularly like the idea of hard coding a user name
and password into the asp or in a vbscript...
Here's how I solved that issue on some of my applications (vbscript-cum-ASP):
I create a user and delegate the AD function I want the script to perform to
it.
I have a table in my SQL that has the username/password combo. In addition to
resticting access to the database, I make sure that the table and the data is
not readily meaningful to any casual observer.
I then set a connectionstring in my Global.asa that connects to this table
In any of my script that need to impersonate a specific user for certain task
(e.g. read/create/delete computer objects), I query for the username/password
combo thus:
myDSN = Application ("myConnectionString")
Set Connect = Server.CreateObject("ADODB.Connection")
Connect.Open myDSN
Set RS = Server.CreateObject("ADODB.Recordset")
RS.Open "SELECT * FROM CreateComputer;", Connect, adOpenStatic
strUsername = RS("LName")
strPassword = RS("LWord")
RS.Close
Connect.Close
set RS = Nothing
Set Connect = Nothing
Then in my LDAP binding I do something like this:
strOU="OU=myOU,DC=mychild,dc=myparent,dc=blah"
Set openDS = GetObject("LDAP:")
Set objContainer = openDS.OpenDSObject(strOU & objDomain, strUsername,
strPassword, 1)
Now, in your case where you have 2 separate non-trusting Forests, what I'd do
create 2 spearate appplication connectionstring, then use the appropriate
connectionstring depending on which Forest you want to manipulate/query.
The first time I set this up, it was VERY time-consuming, but I've since been
rewarded several time over since then by the ease with which I am able to
handle LDAP-binding tasks.
Sincerely,
Dèjì Akómöláfé, MCSE MCSA MCP+I
www.akomolafe.com
www.iyaburo.com
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
________________________________
From: [EMAIL PROTECTED] on behalf of Rich Milburn
Sent: Wed 1/28/2004 8:53 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] read PasswordLastChanged question
Okay since it's not a Monday, mind if I add to the fun here? Let's say we
are going to allow authentication to two domains (separate forests, no
trusts), and now we can't use the machine account (#2). First, I can't
figure out how to use alternate credentials in an LDAP query in vbscript, and
second I don't particularly like the idea of hard coding a user name and
password into the asp or in a vbscript... Here's what I'm thinking now,
along the lines of #1 below:
- The user logs in
- Portal kicks off either domainA or domainB with the username
(sAMAccountName to simplify) as a parameter
- domainA or domainB is a script or exe (maybe from the CPAU tool?) that hits
the appropriate domain, finds the user's DN, grabs the passwordLastChanged
attribute, then hands back how many days old the password is back to the
Portal process that kicked it off.
Does that sound workable?
Thanks
Rich
________________________________
From: joe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 9:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] read PasswordLastChanged question
Solutions to this could be
1. Use an application ID that has an constant open bind to the directory to
pull the needed data.
2. The app runs as a service (localsystem or networkservice) on a machine and
uses the machine's credentials to read the directory. - Note I haven't tried
network service but from what I have heard, it should work.
I wouldn't open anything like that up for anonymous query.
joe
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rich Milburn
Sent: Wednesday, January 28, 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] read PasswordLastChanged question
Given this scenario - a user logs in to a Portal, the Portal then checks
his/her authentication against AD 2003 in order to verify the user/password
combination is valid in AD, and then the Portal creates a token for its own
purposes of navigating through the Portal (as opposed to using AD credentials
to determine authorization) - if you wanted to then retrieve the
PasswordLastChanged property of that user object without making the user log
in again then you'd either have to run the process as a user for the LDAP
query against AD, or grant ANONYMOUS read privilege to
User-password.whenChanged, plus maybe other things - I've never tried
anonymous queries against AD. I think (is this right?) I'm thinking we
don't want to change the permissions, so if we use a restricted user account,
shouldn't we be able to read any user object's PasswordLastChanged property
(Authenticated Users have Read permissions on most all properties, as far as
I could determine)? Are there any gotcha's I should be aware of, and am I
missing anything here?
Thanks
Rich Milburn
MCSE, MS MVP
-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE-------
PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any
attachments. This information is strictly confidential and may be subject to
attorney-client privilege. This message is intended only for the use of the
named addressee. If you are not the intended recipient of this message,
unauthorized forwarding, printing, copying, distribution, or using such
information is strictly prohibited and may be unlawful. If you have received
this in error, you should kindly notify the sender by reply e-mail and
immediately destroy this message. Unauthorized interception of this e-mail is
a violation of federal criminal law. Applebee's International, Inc. reserves
the right to monitor and review the content of all messages sent to and from
this e-mail address. Messages sent to or from this e-mail address may be
stored on the Applebee's International, Inc. e-mail system.
-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE-------
PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any
attachments. This information is strictly confidential and may be subject to
attorney-client privilege. This message is intended only for the use of the
named addressee. If you are not the intended recipient of this message,
unauthorized forwarding, printing, copying, distribution, or using such
information is strictly prohibited and may be unlawful. If you have received
this in error, you should kindly notify the sender by reply e-mail and
immediately destroy this message. Unauthorized interception of this e-mail is
a violation of federal criminal law. Applebee's International, Inc. reserves
the right to monitor and review the content of all messages sent to and from
this e-mail address. Messages sent to or from this e-mail address may be
stored on the Applebee's International, Inc. e-mail system.
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
