If the whole goal is to disallow access to other machines
and it has to be enforced, I would not use a domain ID. I would work with local
IDs on the specific machines, these IDs should not be the same as the IDs on
other machines and shouldn't have passwords in sync. That way if anything breaks
that is supposed to go back and lock down access the folks still don't have
access to other machines. They could have access to log into the local machine
again which may be a pain but if they were just on it, I don't see that as
incredibly bad. You can obviously use the same or a similar mechanism currently
in use to lock down the ID after 2 minutes. Another solution to lock the ID down
quickly on the local machine would be to have a service that just watches an
account and once it shows password not expired, sleep 5 seconds and then change
the password and expire it again. Any lockdown done on a domain ID would not be
fully in effect until replication carried that change to all DCs. It could get
messy if DCs in different sites were used.
I guess if you wanted
to get really fancy (read complex and subject to failure and issues) with a
domain ID you could have a logon script for the ID, the logon script sends a
request to some machine with then locks the ID down, then the script keeps
querying that machine and the machine says STOP until it has detected that the
ID has been locked down on all DCs, then the script gets a GO message to
continue the logon. If the GO doesn't come in x seconds/minutes, the logon
script tells the user there has been a problem and logs them back off without
ever letting them do anything.
Basically, you want them to have a one-time-use password? Is
that correct?
That's interesting. I haven't seen anything like that, but I imagine
that's something that allows an outside vendor to have remote access to do
something they need to do, but for security reasons you wouldn't want them to
have full access to everything.
I wonder if it would be better to grant them access to the machine they'll
access when they reset the password to prevent them from accessing other
machines? i.e. Reset password & limit the desktop they can access at the
same time. Would that give better control?
Aside from that, can you define the exact requirements a little more?
I think it might jar somebody's thinking a little more to hear some additional
information about the requirements.
My initial thought, if the above doesn't get you closer to the
requirements, would be to use a logon script or change in the code to do
this. Maybe with a timer. I.E. reset the password, set it to expire
at x minutes (if that helps), limit the machine it can logon to, and after x
amount of time check for usage. If found, reset the password.
I do have to ask if this would allow them to accomplish the function they
need to accomplish however. I wonder if you're not giving them enough time to do
what they need to do.
My rambling thoughts anyway.
Al
On 1/5/06, Edwin
<[EMAIL PROTECTED]>
wrote:
Hello Everyone,
I
have an application that allows different users to reset a special domain
account that allows for RDP sessions to be established on thousands of
machines on a domain. These usernames have a policy that forces the
password to expire within 2 minutes. If the password has expired, they
must reset the password from within the application again to gain access to
another server.
I
am aware of the password expiration policy(ies), but I would like something
different. What I would like to do is force a user to reset their
password upon first use. As it stands, I can reset the password and
still authenticate to many other servers as long as I am within the 2 minute
expiration rule.
How can I have force a password to
expire upon first use? Is this possible?
Thank you for your
replies,
Edwin
