Ø …You might as well put the server in a workgroup just to be consistent…
Hey no peeking at our network mister J
Ø …I do not recommend hard coding creds into a vbscript or any script. That is a great way to be compromised, to not ever want to change a password, and to find fun ways to lock yourself out…
Yeah that was my thought on it too… about the only influence/involvement I’ve had so far is due to knowing how to access AD through scripting (thanks to this list and Robbie’s cookbook). The problem is that this portal (in the dmz) has the initial authentication routine coded into the app, and [they believe] it would be unsupported to grab that process and use it to check for password expiration. That’s really the only problem, the other stuff can be done with a second login (changing passwords and/or phone number etc). The domain will be set to expire passwords, and if a remote portal user’s password expires he’ll have to call – since you have to authenticate to even get into the portal to access a change password function. Hence the need to proactively warn users ahead of time, and force them to go and change their password.
I like your COM+ idea, and also Jorge sent an interesting idea about using SQL. We’ll see how things go.
Thanks Rich From: joe [mailto:[EMAIL PROTECTED]
Ok you like to play games do ya....
:op
Two non-trusting domains but you want to use one machine to basically skim across both of them. You might as well put the server in a workgroup just to be consistent. :o)
I do not recommend hard coding creds into a vbscript or any script. That is a great way to be compromised, to not ever want to change a password, and to find fun ways to lock yourself out.
So how is the user logon being pulled off? If you have enough info for that logon you have enough to get the pwdlastset attribute like you are thinking, simply bind with the user's creds and have the proper info returned. Alternatively have a nice COM+ object that you send your calls into that is a real executable that goes and does the authentication and gets the info. If you sync the ID that the object is running as between the two domains, it should be able to read both without too much trouble except for the change password maintenance. It could also have maybe a password safe of its own that is encrypted in its own format and it knows how to get at the passwords and use them, this should be something that is easy to change.
I wouldn't want to just say carte blanche this or that would work, that is why in the first response I said "could be...". This is the kind of weird thing that you sit people down in a room and someone spits out what needs to happen and why (so yu can beat up on that and get the real requirements) and the slowly beat out the solution but with everyone understanding the details and consequences.
joe
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Milburn 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]
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 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. -------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. |
Title: Message
- RE: [ActiveDir] read PasswordLastChanged question deji
- Rich Milburn