| Author | Messages | |
Marty1_0
Posts:72
 | | 06/26/2007 3:12 AM |
| Either which way you take, you will have always the same "issues":
- a number of people need the password or the ability to consult it if needed
- make sure that all are updated or have a limited list and reference
- have confidence in the people that have the password
- resetting the password should be done with a domain account, meaning granting that particular user the rights. Use a special account for it? Again same story over again (people need to know, spreading around, ...)
....
But still I'm confident that if you have a proper way to reset the local administrator account on a regular basis (talking about months, not weeks due coverage issues you'll probably face), it's nice to have. The longer a certain account remains with the same password, the more people know the password (I see that happening everywhere) with every consequence afterwards on long term.
As for servers, good server management is the same thing. Local accounts should also be maintained and try to avoid using them. But when needed, you should have the password is case...So after an intervention that was urgent (business critical issues often override security principles), the number of persons knowing the password is extended.
So for both workstations and servers, there isn't actually a good built-in functionality to manage the local accounts. Ex. if a computer/server is a domain member, that you could push a sometime securely by GPO or whatever to have it done. Both are managed totally seperately regarding the passwords which makes the management of it difficult (ex. remarks from Al & Co).
I know a company that actually for certain applications on servers (very restricted ones) is working with a local account to access it. This is resetted each week (or after an intervention)and the password is stored in the mainframe, only accessible by security department. Additionally security monitoring is very high on those systems.
It's going in a good direction, but for servers you haven't the coverage issues you'll have with workstations.
Perhaps one day somebody will have the absolute answer and solution for this.... Untill then we will remain with different point of views depending on the situations (as said by others before).
Cheers,
Bart
On 6/26/07, Boswell, Richard wrote:
RPMEE --> http://www.liebsoft.com/index.cfm/cms?id=270
Cheaper in long run than explaining to your Board\Manager\CSO\CTO\SEC\Secret Service\Wife why you were fired because someone got "THE" password.
Richard Boswell | Systems Engineer |
Windows Server Engineering | Visa | 12357-C Riata Trace Pkwy, Austin, TX 78727 | Work - (512) 506-4643 | Cell - (512) 750-4583
From: ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of joeSent: Tuesday, June 26, 2007 1:27 PMTo:
ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Ah I didn't rewrite, reply all from sent items works faster. :)
As I mentioned before, I try to stay away from the client solutions as much as possible until they impact my Domain Controllers and other utility servers I am responsible for. :)
As to what I would do... that would make a good t-shirt, I will have to think about doing that, could be some good income. ;o) Anyway, my previous post on the pitfalls here should indicate I am not entirely clear what should be done. I think the answer is a function of thesituation at handΏ]. For a military or other high security environment you will have one solution, for a bunch of PCs that you don't care a whole lot about in sort of a crash and burn environment you will have another solution.
I would want to hear goals desires how much money is available to play with etc before I said, this is probably what you are looking for. With what most people seem to be willing to spend and how much they know about security, tossing a
NET USER ADMINISTRATOR MySecretPassword01!
command into a startup script is probably going to be the answer right up until someone crucifies them for that mistake.
A good general purpose solution would be to build (or buy)some sort of special agent that can securely chat with a "home base" server and get the details of the password it should set and when it should do it, etc. It could be just smart enough to check for a password change notification filter. Looking for API interception would likely be above its ability. Any machines you want tohave the password managed on... you load this agent on. It scales, should work through firewalls (if using proper protocols), and should be moderately secure.
joe
Ώ] Fancy way of saying it depends. :)
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al MulnickSent: Tuesday, June 26, 2007 2:03 PMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script local admin password reset
Oddly, that same company XYZ seems to be lacking a way to manage the password use. That's the element that's missing from product-only solutions (we discussed this concept before if you recall.) It's not enough to have a way, but you also must manage it to ensure that it's being used appropriately. Whether that's an automated management process or something where l8 is involved is dependent on the situation and environmental attributes.
Glad you saw fit to write this again. Makes it easier to see what you're thinking....
On 6/26/07, joe < listmail@joeware.net> wrote:
Odd... Two of my messages I sent this morning didn't seem to hit the list...
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: joe [mailto:listmail@joeware.net] Sent: Tuesday, June 26, 2007 9:41 AM
To: 'ActiveDir@mail.activedir.org'Subject: RE: [ActiveDir] startup script local admin password reset
In theory I completely concur with you, but in reality it is a giant "it depends" answer. Workstations, IMO,should be pawns (like DCs) in that you can knock one down and stand another in its place right up with no pain and no fuss. Basically fat versions of thin clients but if thin computing was all that was needed, you could assume that is what the folks would be doing. People are still using fat clients for some reason and that reason couldmean customization or data that someone isn't going to want to lose. Not saying I think it is right that important data should be maintained at the workstation level and not recoverable somewhere else, but again, in reality it happens and there are times when something happens and you need into the box and domain creds aren't doing it.I know I have started out sayingmany times "but that shouldn't be necessary..." only to hear "just make it so...".
As I understand it (and I tried to stay as far away as possible), a certain Company XYZ that we both know uses a special "secret" process of setting the passwords to a fixed value on a regular interval and then you use a special "secret" program on a CD to ascertain thelocal admin password for a given machine whenever it is needed. Also from what I understand, that tends to get used on afairly regular basis whether it is "right" or not. It is just the reality of the situation and if it isn't handled well centrally by a company, the odds are good that local site people will handle it in whatever way they can think of which may not have the thought put into it that is described here.
Theoretically though, I am right there with you. :)
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Austin OsuideSent: Tuesday, June 26, 2007 5:58 AMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script local admin password reset
Interesting reading about the effort put into managing the passwords of local admin accounts, which will never be used by anyone, on domain joined machines. And the larger the org, the larger the effort and cost.
I am yet to find a situation where a local administrative account was required to manage a domain joined machine in prod.
So, if you disable these local admin accounts by setting the password to some v.long random characters, eg page from a random book, you in effect disable the account as not one can guess the password.
Do these for all your local admin accounts and you have saved yourself a pretty bundle.
If the machine ever gets in a twist where you can't use domain accounts, it is usually quicker, in my experience, to rebuild the box. Resumption of normal service is usually the greater driver and RCAs can be done later.
One assumes however, that this is not the only security precaution taken.
Just my £0.02 J
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto: ActiveDir-owner@mail.activedir.org] On Behalf Of
Al MulnickSent: 25 June 2007 20:31To: ActiveDir@mail.activedir.orgSubject:
Re: [ActiveDir] startup script local admin password reset
It is. But I think you have enough of the information regarding pros, cons, and other gotchas to make an informed decision regarding your way forward. Hopefully this has been a helpful discussion :)
On 6/25/07, Matheesha Weerasinghe wrote:
We dont distribute software. The machines gold builds are built with the software each machine needs. Security Updates for the OS are distributed through WSUS. We dont even distribute service packs through it yet. We dont distribute any software using SMS type implementations.
However we are in the process of implementing Radia. Once that goes live, we can distribute a package/script that changes the admin password. I assume this is what you are driving at ;-)M@
On 25/06/07, Al Mulnick wrote:
Let me ask that another way: How do you distribute software today?
On 6/25/07, Matheesha Weerasinghe wrote:
Not yet.
On 24/06/07, Al Mulnick wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe wrote:
The goldbuilds are given to onsite admins who can rebuild the machine if deemed necessary. We allow them to jon the machines to the domain and they have local admin rights on the machine (via the domain accounts). They dont need to know the local admin password and neither do the users. Hence the period recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick wrote:
Seriously? Why are you not able to set the local administrator password to an account you want? You can rename it (so it's not human readable as administrator) and set the password during the build process. You shouldn't build one without a password - the default in Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe < matheesha@gmail.com > wrote:
Remote resetting with an app sounds very good. But the reason we use startup scripts is to ensure the passwords get reset to the values we want after the workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password manually" to the process of rebuilding a workstation, I cant think of any other way to handle machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline wrote:
We found that a traditional VBS startup script was too insecure.The new password was visible within a plain text or easily decrypted file.
I wrote a .net application which remotely attaches to workstations and changes the local administrator password. If you follow this route, I recommend that you store the change attempt results (success or reason for failure) into a database for control and management review.
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
Anuj AttreeSent: Saturday, June 23, 2007 8:04 PMTo: activedir@mail.activedir.org
Subject: [ActiveDir] startup script local admin password reset
Hi All
Need help....I do want to change local admin password of all computers in an example.com domain. I've made a script that does work when run in a virtual environment using 1 dc windows server 2003 and 1 windows xp sp2 client. I followed following steps when doing the same:
1> made a test ou in my example.com domain2> made a gpo and configure startup script, provided share path of the script and log file (the actions are logged in the same)
3> put 1 computer in the test ou4> start the computer and it did workthe same thing i am trying to implement in my company's domain. for testing i've made a test ou and put 5 computers there. created a gpo and provided the share path of the script. but when the computer is started no script run. we're running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:1> made a simple drive mapping script and put it in logon script. it does work. it means gpo has applied on this test ou.2> put admin password change script in the same shared folder and put it in startup script. but it doesn't work.
3> working in a multiple dcs environment, and using the dc which lies in the computers site on which testing is carried out.Please let me know if you require further information in this regards. I do want to implement the same in our domain which would save a lot of time and will automate the activity.
Thanks in advance...
-- RegardsAnuj Attree
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| amulnick
Posts:138
| | 06/26/2007 3:34 AM |
| for the t-shirt idea, see my other OT:: post for some thoughts. I think the bracelet would be better. Might read WWjDITS or something similar :)On 6/26/07,
joe wrote:
Ah I didn't rewrite, reply all from sent items works
faster. :)
As I mentioned before, I try to stay away from the client
solutions as much as possible until they impact my Domain Controllers and other
utility servers I am responsible for. :)
As to what I would do... that would make a good t-shirt, I
will have to think about doing that, could be some good income. ;o)
Anyway, my previous post on the pitfalls here should indicate I am not entirely
clear what should be done. I think the answer is a function of
thesituation at handΏ]. For a military or other high security environment
you will have one solution, for a bunch of PCs that you don't care a whole lot
about in sort of a crash and burn environment you will have another solution.
I would want to hear goals desires how much money is
available to play with etc before I said, this is probably what you are looking
for. With what most people seem to be willing to spend and how much they know
about security, tossing a
NET USER ADMINISTRATOR MySecretPassword01!
command into a startup script is probably going to be the
answer right up until someone crucifies them for that mistake.
A good general purpose solution would be to build (or
buy)some sort of special agent that can securely chat with a "home base"
server and get the details of the password it should set and when it should do
it, etc. It could be just smart enough to check for a password change
notification filter. Looking for API interception would likely be above its
ability. Any machines you want tohave the password managed on... you load
this agent on. It scales, should work through firewalls (if using proper
protocols), and should be moderately secure.
joe
Ώ] Fancy way of saying it depends.
:)
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
MulnickSent: Tuesday, June 26, 2007 2:03 PMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script
local admin password reset
Oddly, that same company XYZ seems to be lacking a way to manage the
password use. That's the element that's missing from product-only
solutions (we discussed this concept before if you recall.) It's not enough to
have a way, but you also must manage it to ensure that it's being used
appropriately. Whether that's an automated management process or something
where l8 is involved is dependent on the situation and environmental attributes.
Glad you saw fit to write this again. Makes it easier to see what
you're thinking....
On 6/26/07, joe
< listmail@joeware.net>
wrote:
Odd... Two
of my messages I sent this morning didn't seem to hit the
list...
--
O'Reilly
Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: joe [mailto:listmail@joeware.net]
Sent: Tuesday, June 26, 2007 9:41 AMTo:
'ActiveDir@mail.activedir.org'Subject: RE:
[ActiveDir] startup script local admin password reset
In theory
I completely concur with you, but in reality it is a giant "it depends"
answer. Workstations, IMO,should be pawns (like DCs) in that you can
knock one down and stand another in its place right up with no pain and no
fuss. Basically fat versions of thin clients but if thin computing was all
that was needed, you could assume that is what the folks would be doing.
People are still using fat clients for some reason and that reason
couldmean customization or data that someone isn't going to want to
lose. Not saying I think it is right that important data should be maintained
at the workstation level and not recoverable somewhere else, but again, in
reality it happens and there are times when something happens and you need
into the box and domain creds aren't doing it.I know I have started out
sayingmany times "but that shouldn't be necessary..." only to hear "just
make it so...".
As I
understand it (and I tried to stay as far away as possible), a certain Company
XYZ that we both know uses a special "secret" process of setting the passwords
to a fixed value on a regular interval and then you use a special "secret"
program on a CD to ascertain thelocal admin password for a given machine
whenever it is needed. Also from what I understand, that tends to get used on
afairly regular basis whether it is "right" or not. It is just the
reality of the situation and if it isn't handled well centrally by a company,
the odds are good that local site people will handle it in whatever way they
can think of which may not have the thought put into it that is described
here.
Theoretically though, I am right there with you.
:)
joe
--
O'Reilly
Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of
Austin OsuideSent: Tuesday, June 26, 2007 5:58 AMTo: ActiveDir@mail.activedir.org
Subject: RE:
[ActiveDir] startup script local admin password reset
Interesting reading
about the effort put into managing the passwords of local admin accounts,
which will never be used by anyone, on domain joined machines. And the larger
the org, the larger the effort and cost.
I am yet to find a
situation where a local administrative account was required to manage a domain
joined machine in prod.
So, if you disable
these local admin accounts by setting the password to some v.long random
characters, eg page from a random book, you in effect disable the account as
not one can guess the password.
Do these for all your
local admin accounts and you have saved yourself a pretty bundle.
If the machine ever
gets in a twist where you can't use domain accounts, it is usually quicker, in
my experience, to rebuild the box. Resumption of normal service is usually the
greater driver and RCAs can be done later.
One assumes however,
that this is not the only security precaution taken.
Just my £0.02
J
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al
MulnickSent: 25 June 2007 20:31To: ActiveDir@mail.activedir.orgSubject:
Re:
[ActiveDir] startup script local admin password reset
It is. But I think you have enough of
the information regarding pros, cons, and other gotchas to make an informed
decision regarding your way forward. Hopefully this has been a helpful
discussion :)
On 6/25/07, Matheesha Weerasinghe
wrote:
We dont distribute software. The machines gold builds are built with the
software each machine needs. Security Updates for the OS are distributed
through WSUS. We dont even distribute service packs through it yet. We dont
distribute any software using SMS type implementations. However we are
in the process of implementing Radia. Once that goes live, we can distribute a
package/script that changes the admin password. I assume this is what you are
driving at ;-)M@
On 25/06/07, Al Mulnick
wrote:
Let me ask that another way: How do you distribute software today?
On 6/25/07, Matheesha Weerasinghe
wrote:
Not yet.
On 24/06/07, Al Mulnick
wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe
wrote:
The goldbuilds are given to onsite admins who can rebuild the machine if
deemed necessary. We allow them to jon the machines to the domain and they
have local admin rights on the machine (via the domain accounts). They dont
need to know the local admin password and neither do the users. Hence the
period recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick
wrote:
Seriously? Why are you not able to set
the local administrator password to an account you want? You can rename
it (so it's not human readable as administrator) and set the password during
the build process. You shouldn't build one without a password - the default in
Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe < matheesha@gmail.com >
wrote:
Remote resetting with an app sounds very good. But the reason we use
startup scripts is to ensure the passwords get reset to the values we want
after the workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password manually" to the
process of rebuilding a workstation, I cant think of any other way to handle
machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline wrote:
We found that a
traditional VBS startup script was too insecure.The new password
was visible within a plain text or easily decrypted file.
I wrote a .net
application which remotely attaches to workstations and changes the local
administrator password. If you follow this route, I recommend that you
store the change attempt results (success or reason for failure) into a
database for control and management review.
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
Anuj AttreeSent: Saturday, June 23, 2007 8:04
PMTo: activedir@mail.activedir.org Subject:
[ActiveDir] startup script local admin password reset
Hi All
Need help....I do want to change local admin password of
all computers in an example.com domain. I've made a
script that does work when run in a virtual environment using 1 dc windows
server 2003 and 1 windows xp sp2 client. I followed following steps when
doing the same: 1> made a test ou in my example.com domain2>
made a gpo and configure startup script, provided share path of the script
and log file (the actions are logged in the same) 3> put 1 computer
in the test ou4> start the computer and it did workthe
same thing i am trying to implement in my company's domain. for testing i've
made a test ou and put 5 computers there. created a gpo and provided the
share path of the script. but when the computer is started no script run.
we're running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:1> made a
simple drive mapping script and put it in logon script. it does work. it
means gpo has applied on this test ou.2> put admin password change
script in the same shared folder and put it in startup script. but it
doesn't work. 3> working in a multiple dcs environment, and using the
dc which lies in the computers site on which testing is carried
out.Please let me know if you require further
information in this regards. I do want to implement the same in our domain
which would save a lot of time and will automate the activity.
Thanks in advance...
-- RegardsAnuj Attree
This message may contain confidential
information and is intended only for the individual named. If you are not
the named addressee you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately by e-mail if you have
received this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept
liability for any errors or omissions in the contents of this message, which
arise as a result of e-mail transmission. If verification is required
please request a digitally signed version. | | | |
| austin
Posts:8
| | 06/26/2007 5:30 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
People,
It’s the local admin password we are talking about here.
What are the situations where this would be useful in a production
environment where you had centralised management with AD.
The “it depends” need to be clear. Or clearer J
Maybe some might use it, but its by choice. If I remember, XYZ
coy had the local admin process in place ‘cause it’s difficult to
accept the concept that for a domain joined box, at least in prod, the local
admin account is of little value. Randomize it’s password and rest easy.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Boswell,
Richard
Sent: 26 June 2007 19:36
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
RPMEE --> http://www.liebsoft.com/index.cfm/cms?id=270
Cheaper in long run than explaining to your
Board\Manager\CSO\CTO\SEC\Secret Service\Wife why you were fired because
someone got "THE" password.
Richard
Boswell |
Systems Engineer | Windows
Server Engineering | Visa | 12357-C Riata Trace Pkwy, Austin, TX 78727 | Work -
(512) 506-4643 | Cell - (512) 750-4583
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of joe
Sent: Tuesday, June 26, 2007 1:27 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Ah I didn't rewrite, reply all from sent items works faster. :)
As I mentioned before, I try to stay away from the client solutions
as much as possible until they impact my Domain Controllers and other utility
servers I am responsible for. :)
As to what I would do... that would make a good t-shirt, I will
have to think about doing that, could be some good income. ;o) Anyway, my
previous post on the pitfalls here should indicate I am not entirely clear what
should be done. I think the answer is a function of thesituation at
handΏ]. For a military or other high security environment you will have one
solution, for a bunch of PCs that you don't care a whole lot about in sort of a
crash and burn environment you will have another solution.
I would want to hear goals desires how much money is available to
play with etc before I said, this is probably what you are looking for. With
what most people seem to be willing to spend and how much they know about
security, tossing a
NET USER ADMINISTRATOR MySecretPassword01!
command into a startup script is probably going to be the answer
right up until someone crucifies them for that mistake.
A good general purpose solution would be to build (or
buy)some sort of special agent that can securely chat with a "home
base" server and get the details of the password it should set and when it
should do it, etc. It could be just smart enough to check for a password change
notification filter. Looking for API interception would likely be above its
ability. Any machines you want tohave the password managed on... you load
this agent on. It scales, should work through firewalls (if using proper
protocols), and should be moderately secure.
joe
Ώ] Fancy way of saying it depends. :)
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Al Mulnick
Sent: Tuesday, June 26, 2007 2:03 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Oddly, that same company XYZ
seems to be lacking a way to manage the password use. That's the element
that's missing from product-only solutions (we discussed this concept before if
you recall.) It's not enough to have a way, but you also must manage it to
ensure that it's being used appropriately. Whether that's an automated
management process or something where l8 is involved is dependent on the
situation and environmental attributes.
Glad you saw fit to write this again. Makes it easier to see what you're
thinking....
On 6/26/07, joe < listmail@joeware.net> wrote:
Odd... Two of my messages I sent this morning didn't seem to hit
the list...
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: joe
[mailto:listmail@joeware.net]
Sent: Tuesday, June 26, 2007 9:41 AM
To: 'ActiveDir@mail.activedir.org'
Subject: RE: [ActiveDir] startup script local admin password reset
In theory I completely concur with you, but in reality it is a
giant "it depends" answer. Workstations, IMO,should be pawns
(like DCs) in that you can knock one down and stand another in its place right
up with no pain and no fuss. Basically fat versions of thin clients but if thin
computing was all that was needed, you could assume that is what the folks
would be doing. People are still using fat clients for some reason and that
reason couldmean customization or data that someone isn't going to want
to lose. Not saying I think it is right that important data should be
maintained at the workstation level and not recoverable somewhere else, but
again, in reality it happens and there are times when something happens and you
need into the box and domain creds aren't doing it.I know I have started
out sayingmany times "but that shouldn't be necessary..." only
to hear "just make it so...".
As I understand it (and I tried to stay as far away as possible), a
certain Company XYZ that we both know uses a special "secret" process
of setting the passwords to a fixed value on a regular interval and then you
use a special "secret" program on a CD to ascertain thelocal
admin password for a given machine whenever it is needed. Also from what I
understand, that tends to get used on afairly regular basis whether it is
"right" or not. It is just the reality of the situation and if it
isn't handled well centrally by a company, the odds are good that local site
people will handle it in whatever way they can think of which may not have the
thought put into it that is described here.
Theoretically though, I am right there with you. :)
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide
Sent: Tuesday, June 26, 2007 5:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Interesting reading about the
effort put into managing the passwords of local admin accounts, which will
never be used by anyone, on domain joined machines. And the larger the org, the
larger the effort and cost.
I am yet to find a situation
where a local administrative account was required to manage a domain joined
machine in prod.
So, if you disable these local
admin accounts by setting the password to some v.long random characters, eg
page from a random book, you in effect disable the account as not one can guess
the password.
Do these for all your local
admin accounts and you have saved yourself a pretty bundle.
If the machine ever gets in a
twist where you can't use domain accounts, it is usually quicker, in my
experience, to rebuild the box. Resumption of normal service is usually the
greater driver and RCAs can be done later.
One assumes however, that this
is not the only security precaution taken.
Just my £0.02 J
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 25 June 2007 20:31
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
It is.
But I think you have enough of the information regarding pros, cons, and other
gotchas to make an informed decision regarding your way forward. Hopefully this
has been a helpful discussion :)
On 6/25/07, Matheesha Weerasinghe
wrote:
We dont distribute software. The machines gold builds are built with the
software each machine needs. Security Updates for the OS are distributed
through WSUS. We dont even distribute service packs through it yet. We dont
distribute any software using SMS type implementations.
However we are in the process of implementing Radia. Once that goes live, we
can distribute a package/script that changes the admin password. I assume this
is what you are driving at ;-)
M@
On 25/06/07, Al Mulnick wrote:
Let me ask that another way: How do you distribute software today?
On 6/25/07, Matheesha Weerasinghe
wrote:
Not yet.
On 24/06/07, Al Mulnick wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe
wrote:
The goldbuilds are given to onsite admins who can rebuild the machine if
deemed necessary. We allow them to jon the machines to the domain and they have
local admin rights on the machine (via the domain accounts). They dont need to
know the local admin password and neither do the users. Hence the period
recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick wrote:
Seriously?
Why are you not able to set the local administrator password to an account you
want? You can rename it (so it's not human readable as administrator) and
set the password during the build process. You shouldn't build one without a
password - the default in Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe < matheesha@gmail.com >
wrote:
Remote resetting with an app sounds very good. But the reason we use startup
scripts is to ensure the passwords get reset to the values we want after the
workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password manually" to
the process of rebuilding a workstation, I cant think of any other way to
handle machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline > wrote:
We found that a
traditional VBS startup script was too insecure.The new password was
visible within a plain text or easily decrypted file.
I wrote a .net
application which remotely attaches to workstations and changes the local
administrator password. If you follow this route, I recommend that you store
the change attempt results (success or reason for failure) into a database for
control and management review.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 8:04 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] startup script local admin password reset
Hi All
Need help....
I do want to change local admin password of all computers in an example.com domain. I've made a
script that does work when run in a virtual environment using 1 dc windows
server 2003 and 1 windows xp sp2 client. I followed following steps when doing
the same:
1> made a test ou in my example.com
domain
2> made a gpo and configure startup script, provided share path of the
script and log file (the actions are logged in the same)
3> put 1 computer in the test ou
4> start the computer and it did work
the same thing i am trying to implement in my company's domain. for testing
i've made a test ou and put 5 computers there. created a gpo and provided the
share path of the script. but when the computer is started no script run. we're
running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:
1> made a simple drive mapping script and put it in logon script. it does
work. it means gpo has applied on this test ou.
2> put admin password change script in the same shared folder and put it in
startup script. but it doesn't work.
3> working in a multiple dcs environment, and using the dc which lies in the
computers site on which testing is carried out.
Please let me know if you require further information in this regards. I do
want to implement the same in our domain which would save a lot of time and
will automate the activity.
Thanks in advance...
--
Regards
Anuj Attree
This message may contain
confidential information and is intended only for the individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as information
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| amulnick
Posts:138
| | 06/26/2007 5:42 AM |
| Did you get a chance to read my earlier reply? I gave several examples. Were they not clear? Did you not think that was relevant to the examples in helping to clarify the issues and times when you might use the local administrator credentials? Help me understand what you need to know to clarify.
AlOn 6/26/07, Austin Osuide wrote:
People,
It's the local admin password we are talking about here.
What are the situations where this would be useful in a production
environment where you had centralised management with AD.
The "it depends" need to be clear. Or clearer J
Maybe some might use it, but its by choice. If I remember, XYZ
coy had the local admin process in place 'cause it's difficult to
accept the concept that for a domain joined box, at least in prod, the local
admin account is of little value. Randomize it's password and rest easy.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Boswell,
Richard
Sent: 26 June 2007 19:36
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
RPMEE --> http://www.liebsoft.com/index.cfm/cms?id=270
Cheaper in long run than explaining to your
Board\Manager\CSO\CTO\SEC\Secret Service\Wife why you were fired because
someone got "THE" password.
Richard
Boswell |
Systems Engineer | Windows
Server Engineering | Visa | 12357-C Riata Trace Pkwy, Austin, TX 78727 | Work -
(512) 506-4643 | Cell - (512) 750-4583
From:
ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On
Behalf Of joe
Sent: Tuesday, June 26, 2007 1:27 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Ah I didn't rewrite, reply all from sent items works faster. :)
As I mentioned before, I try to stay away from the client solutions
as much as possible until they impact my Domain Controllers and other utility
servers I am responsible for. :)
As to what I would do... that would make a good t-shirt, I will
have to think about doing that, could be some good income. ;o) Anyway, my
previous post on the pitfalls here should indicate I am not entirely clear what
should be done. I think the answer is a function of thesituation at
handΏ]. For a military or other high security environment you will have one
solution, for a bunch of PCs that you don't care a whole lot about in sort of a
crash and burn environment you will have another solution.
I would want to hear goals desires how much money is available to
play with etc before I said, this is probably what you are looking for. With
what most people seem to be willing to spend and how much they know about
security, tossing a
NET USER ADMINISTRATOR MySecretPassword01!
command into a startup script is probably going to be the answer
right up until someone crucifies them for that mistake.
A good general purpose solution would be to build (or
buy)some sort of special agent that can securely chat with a "home
base" server and get the details of the password it should set and when it
should do it, etc. It could be just smart enough to check for a password change
notification filter. Looking for API interception would likely be above its
ability. Any machines you want tohave the password managed on... you load
this agent on. It scales, should work through firewalls (if using proper
protocols), and should be moderately secure.
joe
Ώ] Fancy way of saying it depends. :)
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On
Behalf Of Al Mulnick
Sent: Tuesday, June 26, 2007 2:03 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Oddly, that same company XYZ
seems to be lacking a way to manage the password use. That's the element
that's missing from product-only solutions (we discussed this concept before if
you recall.) It's not enough to have a way, but you also must manage it to
ensure that it's being used appropriately. Whether that's an automated
management process or something where l8 is involved is dependent on the
situation and environmental attributes.
Glad you saw fit to write this again. Makes it easier to see what you're
thinking....
On 6/26/07, joe < listmail@joeware.net> wrote:
Odd... Two of my messages I sent this morning didn't seem to hit
the list...
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: joe
[mailto:listmail@joeware.net]
Sent: Tuesday, June 26, 2007 9:41 AM
To: 'ActiveDir@mail.activedir.org'
Subject: RE: [ActiveDir] startup script local admin password reset
In theory I completely concur with you, but in reality it is a
giant "it depends" answer. Workstations, IMO,should be pawns
(like DCs) in that you can knock one down and stand another in its place right
up with no pain and no fuss. Basically fat versions of thin clients but if thin
computing was all that was needed, you could assume that is what the folks
would be doing. People are still using fat clients for some reason and that
reason couldmean customization or data that someone isn't going to want
to lose. Not saying I think it is right that important data should be
maintained at the workstation level and not recoverable somewhere else, but
again, in reality it happens and there are times when something happens and you
need into the box and domain creds aren't doing it.I know I have started
out sayingmany times "but that shouldn't be necessary..." only
to hear "just make it so...".
As I understand it (and I tried to stay as far away as possible), a
certain Company XYZ that we both know uses a special "secret" process
of setting the passwords to a fixed value on a regular interval and then you
use a special "secret" program on a CD to ascertain thelocal
admin password for a given machine whenever it is needed. Also from what I
understand, that tends to get used on afairly regular basis whether it is
"right" or not. It is just the reality of the situation and if it
isn't handled well centrally by a company, the odds are good that local site
people will handle it in whatever way they can think of which may not have the
thought put into it that is described here.
Theoretically though, I am right there with you. :)
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide
Sent: Tuesday, June 26, 2007 5:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Interesting reading about the
effort put into managing the passwords of local admin accounts, which will
never be used by anyone, on domain joined machines. And the larger the org, the
larger the effort and cost.
I am yet to find a situation
where a local administrative account was required to manage a domain joined
machine in prod.
So, if you disable these local
admin accounts by setting the password to some v.long random characters, eg
page from a random book, you in effect disable the account as not one can guess
the password.
Do these for all your local
admin accounts and you have saved yourself a pretty bundle.
If the machine ever gets in a
twist where you can't use domain accounts, it is usually quicker, in my
experience, to rebuild the box. Resumption of normal service is usually the
greater driver and RCAs can be done later.
One assumes however, that this
is not the only security precaution taken.
Just my £0.02 J
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 25 June 2007 20:31
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
It is.
But I think you have enough of the information regarding pros, cons, and other
gotchas to make an informed decision regarding your way forward. Hopefully this
has been a helpful discussion :)
On 6/25/07, Matheesha Weerasinghe
wrote:
We dont distribute software. The machines gold builds are built with the
software each machine needs. Security Updates for the OS are distributed
through WSUS. We dont even distribute service packs through it yet. We dont
distribute any software using SMS type implementations.
However we are in the process of implementing Radia. Once that goes live, we
can distribute a package/script that changes the admin password. I assume this
is what you are driving at ;-)
M@
On 25/06/07, Al Mulnick wrote:
Let me ask that another way: How do you distribute software today?
On 6/25/07, Matheesha Weerasinghe
wrote:
Not yet.
On 24/06/07, Al Mulnick wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe
wrote:
The goldbuilds are given to onsite admins who can rebuild the machine if
deemed necessary. We allow them to jon the machines to the domain and they have
local admin rights on the machine (via the domain accounts). They dont need to
know the local admin password and neither do the users. Hence the period
recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick wrote:
Seriously?
Why are you not able to set the local administrator password to an account you
want? You can rename it (so it's not human readable as administrator) and
set the password during the build process. You shouldn't build one without a
password - the default in Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe < matheesha@gmail.com >
wrote:
Remote resetting with an app sounds very good. But the reason we use startup
scripts is to ensure the passwords get reset to the values we want after the
workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password manually" to
the process of rebuilding a workstation, I cant think of any other way to
handle machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline > wrote:
We found that a
traditional VBS startup script was too insecure.The new password was
visible within a plain text or easily decrypted file.
I wrote a .net
application which remotely attaches to workstations and changes the local
administrator password. If you follow this route, I recommend that you store
the change attempt results (success or reason for failure) into a database for
control and management review.
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 8:04 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] startup script local admin password reset
Hi All
Need help....
I do want to change local admin password of all computers in an example.com domain. I've made a
script that does work when run in a virtual environment using 1 dc windows
server 2003 and 1 windows xp sp2 client. I followed following steps when doing
the same:
1> made a test ou in my example.com
domain
2> made a gpo and configure startup script, provided share path of the
script and log file (the actions are logged in the same)
3> put 1 computer in the test ou
4> start the computer and it did work
the same thing i am trying to implement in my company's domain. for testing
i've made a test ou and put 5 computers there. created a gpo and provided the
share path of the script. but when the computer is started no script run. we're
running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:
1> made a simple drive mapping script and put it in logon script. it does
work. it means gpo has applied on this test ou.
2> put admin password change script in the same shared folder and put it in
startup script. but it doesn't work.
3> working in a multiple dcs environment, and using the dc which lies in the
computers site on which testing is carried out.
Please let me know if you require further information in this regards. I do
want to implement the same in our domain which would save a lot of time and
will automate the activity.
Thanks in advance...
--
Regards
Anuj Attree
This message may contain
confidential information and is intended only for the individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as information
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| austin
Posts:8
| | 06/26/2007 5:58 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Interesting reading about the effort put into managing the
passwords of local admin accounts, which will never be used by anyone, on
domain joined machines. And the larger the org, the larger the effort and cost.
I am yet to find a situation where a local administrative
account was required to manage a domain joined machine in prod.
So, if you disable these local admin accounts by setting the
password to some v.long random characters, eg page from a random book, you in
effect disable the account as not one can guess the password.
Do these for all your local admin accounts and you have saved
yourself a pretty bundle.
If the machine ever gets in a twist where you can’t use domain
accounts, it is usually quicker, in my experience, to rebuild the box. Resumption
of normal service is usually the greater driver and RCAs can be done later.
One assumes however, that this is not the only security
precaution taken.
Just my £0.02 J
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: 25 June 2007 20:31
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
It is.
But I think you have enough of the information regarding pros, cons, and other
gotchas to make an informed decision regarding your way forward. Hopefully this
has been a helpful discussion :)
On 6/25/07, Matheesha Weerasinghe
wrote:
We dont distribute software. The machines gold builds are
built with the software each machine needs. Security Updates for the OS are
distributed through WSUS. We dont even distribute service packs through it yet.
We dont distribute any software using SMS type implementations.
However we are in the process of implementing Radia. Once that goes live, we
can distribute a package/script that changes the admin password. I assume this
is what you are driving at ;-)
M@
On 25/06/07, Al Mulnick wrote:
Let me ask that another way: How do you distribute software
today?
On 6/25/07, Matheesha Weerasinghe
wrote:
Not yet.
On 24/06/07, Al Mulnick
wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe
wrote:
The goldbuilds are given to onsite admins who can rebuild
the machine if deemed necessary. We allow them to jon the machines to the
domain and they have local admin rights on the machine (via the domain
accounts). They dont need to know the local admin password and neither do the
users. Hence the period recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick
wrote:
Seriously?
Why are you not able to set the local administrator password to an account you
want? You can rename it (so it's not human readable as administrator) and
set the password during the build process. You shouldn't build one without a
password - the default in Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe
< matheesha@gmail.com >
wrote:
Remote resetting with an app sounds very good. But the
reason we use startup scripts is to ensure the passwords get reset to the
values we want after the workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password
manually" to the process of rebuilding a workstation, I cant think of any
other way to handle machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline
> wrote:
We found that a traditional VBS startup script was too
insecure.The new password was visible within a plain text or easily
decrypted file.
I wrote a .net application which remotely attaches to workstations
and changes the local administrator password. If you follow this route, I
recommend that you store the change attempt results (success or reason for
failure) into a database for control and management review.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 8:04 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] startup script local admin password reset
Hi All
Need help....
I do want to change local admin password of all computers in an example.com domain. I've made a
script that does work when run in a virtual environment using 1 dc windows
server 2003 and 1 windows xp sp2 client. I followed following steps when doing
the same:
1> made a test ou in my example.com
domain
2> made a gpo and configure startup script, provided share path of the
script and log file (the actions are logged in the same)
3> put 1 computer in the test ou
4> start the computer and it did work
the same thing i am trying to implement in my company's domain. for testing
i've made a test ou and put 5 computers there. created a gpo and provided the
share path of the script. but when the computer is started no script run. we're
running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:
1> made a simple drive mapping script and put it in logon script. it does
work. it means gpo has applied on this test ou.
2> put admin password change script in the same shared folder and put it in
startup script. but it doesn't work.
3> working in a multiple dcs environment, and using the dc which lies in the
computers site on which testing is carried out.
Please let me know if you require further information in this regards. I do
want to implement the same in our domain which would save a lot of time and
will automate the activity.
Thanks in advance...
--
Regards
Anuj Attree
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| austin
Posts:8
| | 06/26/2007 7:36 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Al,
With all due respect,
ß-----------à
For example, as I was typing this message I was interrupted
by a colleague looking for help troubleshooting a machine that was losing its
mind and not participating in the domain longer than a day. We had to use
the local administrator account because, well, it could not participate with
the domain properly. We come to find out that a new driver has been used on the
NIC and was introduced in our build process just recently. Would it have
been faster to re image? Likely. Would we have gotten the same
results? Likely. In the end, we would still be chasing tails trying to
get the user to work if we had used the re image method of
troubleshooting. Earlier helping the same colleague with a machine that
had a corrupted sdb file. Same thing. I could use domain credentials
there, but had I just wanted to re-image it would have been dicey. I have
a large portion of the user population that work remotely (from home mostly)
and using domain credentials is not always practical for those users. Etc.
ß-----------à
That was what I wanted cleared up. I’d much rather give you a
headache in solving those issues with a rebuild or adequate testing of your
drivers before they go live than spending gadzillions buying some password
manager that would only add to the problem. As you say in your examples, you
could fix the issues some other way with domain creds sometimes. My point
exactly.
The proper management of local admin passwords in a way they can
be stored securely and released securely on demand is such a headache to maintain
and manage that it is most times not worth the effort. And the larger the env,
the bigger the problem. Once you get your head round it, you start to see the
value of increasing the security of domain joined machines by obfuscating local
admin passwords.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 26 June 2007 22:43
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Did you get a chance to read my
earlier reply? I gave several examples. Were they not clear? Did you not think
that was relevant to the examples in helping to clarify the issues and times
when you might use the local administrator credentials? Help me understand what
you need to know to clarify.
Al
On 6/26/07, Austin Osuide wrote:
People,
It's the local admin password
we are talking about here.
What are the situations where
this would be useful in a production environment where you had centralised
management with AD.
The "it depends" need
to be clear. Or clearer J
Maybe some might use it, but
its by choice. If I remember, XYZ coy had the local admin process in place
'cause it's difficult to accept the concept that for a domain joined box, at
least in prod, the local admin account is of little value. Randomize it's
password and rest easy.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Boswell, Richard
Sent: 26 June 2007 19:36
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin
password reset
RPMEE --> http://www.liebsoft.com/index.cfm/cms?id=270
Cheaper in long run than
explaining to your Board\Manager\CSO\CTO\SEC\Secret Service\Wife why you were
fired because someone got "THE" password.
Richard Boswell | Systems Engineer
| Windows Server
Engineering | Visa | 12357-C Riata Trace Pkwy, Austin, TX 78727 | Work - (512)
506-4643 | Cell - (512) 750-4583
From: ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, June 26, 2007 1:27 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Ah I didn't rewrite, reply all
from sent items works faster. :)
As I mentioned before, I try to
stay away from the client solutions as much as possible until they impact my
Domain Controllers and other utility servers I am responsible for. :)
As to what I would do... that
would make a good t-shirt, I will have to think about doing that, could be some
good income. ;o) Anyway, my previous post on the pitfalls here should
indicate I am not entirely clear what should be done. I think the answer is a
function of thesituation at handΏ]. For a military or other high security
environment you will have one solution, for a bunch of PCs that you don't care
a whole lot about in sort of a crash and burn environment you will have another
solution.
I would want to hear goals desires
how much money is available to play with etc before I said, this is probably
what you are looking for. With what most people seem to be willing to spend and
how much they know about security, tossing a
NET USER ADMINISTRATOR
MySecretPassword01!
command into a startup script is
probably going to be the answer right up until someone crucifies them for that
mistake.
A good general purpose solution
would be to build (or buy)some sort of special agent that can securely
chat with a "home base" server and get the details of the password it
should set and when it should do it, etc. It could be just smart enough to
check for a password change notification filter. Looking for API interception
would likely be above its ability. Any machines you want tohave the
password managed on... you load this agent on. It scales, should work
through firewalls (if using proper protocols), and should be moderately secure.
joe
Ώ] Fancy way of saying it
depends. :)
--
O'Reilly Active Directory Third
Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: Tuesday, June 26, 2007 2:03 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Oddly, that same company XYZ seems to be
lacking a way to manage the password use. That's the element that's
missing from product-only solutions (we discussed this concept before if you
recall.) It's not enough to have a way, but you also must manage it to ensure
that it's being used appropriately. Whether that's an automated
management process or something where l8 is involved is dependent on the
situation and environmental attributes.
Glad you saw fit to write this again. Makes it easier to see what you're
thinking....
On 6/26/07, joe < listmail@joeware.net> wrote:
Odd... Two of my messages I sent
this morning didn't seem to hit the list...
--
O'Reilly Active Directory Third
Edition - http://www.joeware.net/win/ad3e.htm
From: joe [mailto:listmail@joeware.net]
Sent: Tuesday, June 26, 2007 9:41 AM
To: 'ActiveDir@mail.activedir.org'
Subject: RE: [ActiveDir] startup script local admin password reset
In theory I completely concur with
you, but in reality it is a giant "it depends" answer. Workstations,
IMO,should be pawns (like DCs) in that you can knock one down and stand
another in its place right up with no pain and no fuss. Basically fat versions
of thin clients but if thin computing was all that was needed, you could assume
that is what the folks would be doing. People are still using fat clients for
some reason and that reason couldmean customization or data that someone
isn't going to want to lose. Not saying I think it is right that important data
should be maintained at the workstation level and not recoverable somewhere
else, but again, in reality it happens and there are times when something
happens and you need into the box and domain creds aren't doing it.I know
I have started out sayingmany times "but that shouldn't be
necessary..." only to hear "just make it so...".
As I understand it (and I tried to
stay as far away as possible), a certain Company XYZ that we both know uses a
special "secret" process of setting the passwords to a fixed value on
a regular interval and then you use a special "secret" program on a
CD to ascertain thelocal admin password for a given machine whenever it
is needed. Also from what I understand, that tends to get used on afairly
regular basis whether it is "right" or not. It is just the reality of
the situation and if it isn't handled well centrally by a company, the odds are
good that local site people will handle it in whatever way they can think of
which may not have the thought put into it that is described here.
Theoretically though, I am right
there with you. :)
joe
--
O'Reilly Active Directory Third
Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide
Sent: Tuesday, June 26, 2007 5:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Interesting reading about the
effort put into managing the passwords of local admin accounts, which will
never be used by anyone, on domain joined machines. And the larger the org, the
larger the effort and cost.
I am yet to find a situation
where a local administrative account was required to manage a domain joined
machine in prod.
So, if you disable these local
admin accounts by setting the password to some v.long random characters, eg
page from a random book, you in effect disable the account as not one can guess
the password.
Do these for all your local
admin accounts and you have saved yourself a pretty bundle.
If the machine ever gets in a
twist where you can't use domain accounts, it is usually quicker, in my
experience, to rebuild the box. Resumption of normal service is usually the
greater driver and RCAs can be done later.
One assumes however, that this
is not the only security precaution taken.
Just my £0.02 J
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 25 June 2007 20:31
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
It is.
But I think you have enough of the information regarding pros, cons, and other
gotchas to make an informed decision regarding your way forward. Hopefully this
has been a helpful discussion :)
On 6/25/07, Matheesha Weerasinghe
wrote:
We dont distribute software. The machines gold builds are built with the software
each machine needs. Security Updates for the OS are distributed through WSUS.
We dont even distribute service packs through it yet. We dont distribute any
software using SMS type implementations.
However we are in the process of implementing Radia. Once that goes live, we
can distribute a package/script that changes the admin password. I assume this
is what you are driving at ;-)
M@
On 25/06/07, Al Mulnick wrote:
Let me ask that another way: How do you distribute software today?
On 6/25/07, Matheesha Weerasinghe
wrote:
Not yet.
On 24/06/07, Al Mulnick wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe
wrote:
The goldbuilds are given to onsite admins who can rebuild the machine if
deemed necessary. We allow them to jon the machines to the domain and they have
local admin rights on the machine (via the domain accounts). They dont need to
know the local admin password and neither do the users. Hence the period
recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick wrote:
Seriously?
Why are you not able to set the local administrator password to an account you
want? You can rename it (so it's not human readable as administrator) and
set the password during the build process. You shouldn't build one without a
password - the default in Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe < matheesha@gmail.com >
wrote:
Remote resetting with an app sounds very good. But the reason we use startup
scripts is to ensure the passwords get reset to the values we want after the
workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password manually" to
the process of rebuilding a workstation, I cant think of any other way to
handle machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline > wrote:
We found that a
traditional VBS startup script was too insecure.The new password
was visible within a plain text or easily decrypted file.
I wrote a .net
application which remotely attaches to workstations and changes the local
administrator password. If you follow this route, I recommend that you
store the change attempt results (success or reason for failure) into a
database for control and management review.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 8:04 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] startup script local admin password reset
Hi All
Need help....
I do want to change local admin password of all computers in an example.com domain. I've made a
script that does work when run in a virtual environment using 1 dc windows
server 2003 and 1 windows xp sp2 client. I followed following steps when doing
the same:
1> made a test ou in my example.com
domain
2> made a gpo and configure startup script, provided share path of the
script and log file (the actions are logged in the same)
3> put 1 computer in the test ou
4> start the computer and it did work
the same thing i am trying to implement in my company's domain. for testing
i've made a test ou and put 5 computers there. created a gpo and provided the
share path of the script. but when the computer is started no script run. we're
running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:
1> made a simple drive mapping script and put it in logon script. it does
work. it means gpo has applied on this test ou.
2> put admin password change script in the same shared folder and put it in
startup script. but it doesn't work.
3> working in a multiple dcs environment, and using the dc which lies in the
computers site on which testing is carried out.
Please let me know if you require further information in this regards. I do
want to implement the same in our domain which would save a lot of time and
will automate the activity.
Thanks in advance...
--
Regards
Anuj Attree
This message may contain confidential information and is intended only for
the individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
This message may contain
confidential information and is intended only for the individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| amulnick
Posts:138
| | 06/26/2007 7:46 AM |
| I see your point except the part about security through obscurity. But I get it. I just disagree that it would be better to force the issue in all environments. My experience leads me to believe that domain only access would have made the resolution of the issues far worse. Since testing can only test for the scenarios dreamed up, that would not help me in cases such as these. It might make the idea to invest the test and development cycle more palatable, especially if the cost is less than a program and time to change the local administrator password to some random password in the off-chance that somebody might learn it and try to use it everywhere to spread malicious code (could happen of course.)
That, and my users need to have local administrative privs away. If Microsoft is listening, make it better ;) Ώ]AlΏ] What? Vista? Ok, that solves all my problems and world hunger. Right. Now, go and get my ISV's to update their stuff to work with your platform in a way that I don't have to give a user local administrative privs.ΐ]
ΐ] What's that? Don't buy that software for the desktop? Well, Ok. I'll have to invent the time machine first though since this architecture predates me and since many of the ISV's are the only players in town. Darn that reliable software....if only it would become suddenly unreliable then I could have the justification I need to spend oodles of money and time to properly test and deploy software that doesn't require local administrative privs. Then I could prevent users from storing information locally and THEN I could do away with the local administrator password. I would not need it or the expensive software to work around the years of other workarounds. Yep, that should do it. Α]
Α] nothing for here. I just felt that a third sub note should be here. AlOn 6/26/07, Austin Osuide <
austin@osuide.com> wrote:
Al,
With all due respect,
ß-----------
à
For example, as I was typing this message I was interrupted
by a colleague looking for help troubleshooting a machine that was losing its
mind and not participating in the domain longer than a day. We had to use
the local administrator account because, well, it could not participate with
the domain properly. We come to find out that a new driver has been used on the
NIC and was introduced in our build process just recently. Would it have
been faster to re image? Likely. Would we have gotten the same
results? Likely. In the end, we would still be chasing tails trying to
get the user to work if we had used the re image method of
troubleshooting. Earlier helping the same colleague with a machine that
had a corrupted sdb file. Same thing. I could use domain credentials
there, but had I just wanted to re-image it would have been dicey. I have
a large portion of the user population that work remotely (from home mostly)
and using domain credentials is not always practical for those users. Etc.
ß-----------à
That was what I wanted cleared up. I'd much rather give you a
headache in solving those issues with a rebuild or adequate testing of your
drivers before they go live than spending gadzillions buying some password
manager that would only add to the problem. As you say in your examples, you
could fix the issues some other way with domain creds sometimes. My point
exactly.
The proper management of local admin passwords in a way they can
be stored securely and released securely on demand is such a headache to maintain
and manage that it is most times not worth the effort. And the larger the env,
the bigger the problem. Once you get your head round it, you start to see the
value of increasing the security of domain joined machines by obfuscating local
admin passwords.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 26 June 2007 22:43
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Did you get a chance to read my
earlier reply? I gave several examples. Were they not clear? Did you not think
that was relevant to the examples in helping to clarify the issues and times
when you might use the local administrator credentials? Help me understand what
you need to know to clarify.
Al
On 6/26/07, Austin Osuide wrote:
People,
It's the local admin password
we are talking about here.
What are the situations where
this would be useful in a production environment where you had centralised
management with AD.
The "it depends" need
to be clear. Or clearer J
Maybe some might use it, but
its by choice. If I remember, XYZ coy had the local admin process in place
'cause it's difficult to accept the concept that for a domain joined box, at
least in prod, the local admin account is of little value. Randomize it's
password and rest easy.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Boswell, Richard
Sent: 26 June 2007 19:36
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin
password reset
RPMEE --> http://www.liebsoft.com/index.cfm/cms?id=270
Cheaper in long run than
explaining to your Board\Manager\CSO\CTO\SEC\Secret Service\Wife why you were
fired because someone got "THE" password.
Richard Boswell | Systems Engineer
| Windows Server
Engineering | Visa | 12357-C Riata Trace Pkwy, Austin, TX 78727 | Work - (512)
506-4643 | Cell - (512) 750-4583
From:
ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Tuesday, June 26, 2007 1:27 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Ah I didn't rewrite, reply all
from sent items works faster. :)
As I mentioned before, I try to
stay away from the client solutions as much as possible until they impact my
Domain Controllers and other utility servers I am responsible for. :)
As to what I would do... that
would make a good t-shirt, I will have to think about doing that, could be some
good income. ;o) Anyway, my previous post on the pitfalls here should
indicate I am not entirely clear what should be done. I think the answer is a
function of thesituation at handΏ]. For a military or other high security
environment you will have one solution, for a bunch of PCs that you don't care
a whole lot about in sort of a crash and burn environment you will have another
solution.
I would want to hear goals desires
how much money is available to play with etc before I said, this is probably
what you are looking for. With what most people seem to be willing to spend and
how much they know about security, tossing a
NET USER ADMINISTRATOR
MySecretPassword01!
command into a startup script is
probably going to be the answer right up until someone crucifies them for that
mistake.
A good general purpose solution
would be to build (or buy)some sort of special agent that can securely
chat with a "home base" server and get the details of the password it
should set and when it should do it, etc. It could be just smart enough to
check for a password change notification filter. Looking for API interception
would likely be above its ability. Any machines you want tohave the
password managed on... you load this agent on. It scales, should work
through firewalls (if using proper protocols), and should be moderately secure.
joe
Ώ] Fancy way of saying it
depends. :)
--
O'Reilly Active Directory Third
Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: Tuesday, June 26, 2007 2:03 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Oddly, that same company XYZ seems to be
lacking a way to manage the password use. That's the element that's
missing from product-only solutions (we discussed this concept before if you
recall.) It's not enough to have a way, but you also must manage it to ensure
that it's being used appropriately. Whether that's an automated
management process or something where l8 is involved is dependent on the
situation and environmental attributes.
Glad you saw fit to write this again. Makes it easier to see what you're
thinking....
On 6/26/07, joe < listmail@joeware.net> wrote:
Odd... Two of my messages I sent
this morning didn't seem to hit the list...
--
O'Reilly Active Directory Third
Edition - http://www.joeware.net/win/ad3e.htm
From: joe [mailto:
listmail@joeware.net]
Sent: Tuesday, June 26, 2007 9:41 AM
To: 'ActiveDir@mail.activedir.org'
Subject: RE: [ActiveDir] startup script local admin password reset
In theory I completely concur with
you, but in reality it is a giant "it depends" answer. Workstations,
IMO,should be pawns (like DCs) in that you can knock one down and stand
another in its place right up with no pain and no fuss. Basically fat versions
of thin clients but if thin computing was all that was needed, you could assume
that is what the folks would be doing. People are still using fat clients for
some reason and that reason couldmean customization or data that someone
isn't going to want to lose. Not saying I think it is right that important data
should be maintained at the workstation level and not recoverable somewhere
else, but again, in reality it happens and there are times when something
happens and you need into the box and domain creds aren't doing it.I know
I have started out sayingmany times "but that shouldn't be
necessary..." only to hear "just make it so...".
As I understand it (and I tried to
stay as far away as possible), a certain Company XYZ that we both know uses a
special "secret" process of setting the passwords to a fixed value on
a regular interval and then you use a special "secret" program on a
CD to ascertain thelocal admin password for a given machine whenever it
is needed. Also from what I understand, that tends to get used on afairly
regular basis whether it is "right" or not. It is just the reality of
the situation and if it isn't handled well centrally by a company, the odds are
good that local site people will handle it in whatever way they can think of
which may not have the thought put into it that is described here.
Theoretically though, I am right
there with you. :)
joe
--
O'Reilly Active Directory Third
Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide
Sent: Tuesday, June 26, 2007 5:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Interesting reading about the
effort put into managing the passwords of local admin accounts, which will
never be used by anyone, on domain joined machines. And the larger the org, the
larger the effort and cost.
I am yet to find a situation
where a local administrative account was required to manage a domain joined
machine in prod.
So, if you disable these local
admin accounts by setting the password to some v.long random characters, eg
page from a random book, you in effect disable the account as not one can guess
the password.
Do these for all your local
admin accounts and you have saved yourself a pretty bundle.
If the machine ever gets in a
twist where you can't use domain accounts, it is usually quicker, in my
experience, to rebuild the box. Resumption of normal service is usually the
greater driver and RCAs can be done later.
One assumes however, that this
is not the only security precaution taken.
Just my £0.02 J
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org
[mailto:
ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 25 June 2007 20:31
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
It is.
But I think you have enough of the information regarding pros, cons, and other
gotchas to make an informed decision regarding your way forward. Hopefully this
has been a helpful discussion :)
On 6/25/07, Matheesha Weerasinghe
wrote:
We dont distribute software. The machines gold builds are built with the software
each machine needs. Security Updates for the OS are distributed through WSUS.
We dont even distribute service packs through it yet. We dont distribute any
software using SMS type implementations.
However we are in the process of implementing Radia. Once that goes live, we
can distribute a package/script that changes the admin password. I assume this
is what you are driving at ;-)
M@
On 25/06/07, Al Mulnick wrote:
Let me ask that another way: How do you distribute software today?
On 6/25/07, Matheesha Weerasinghe
wrote:
Not yet.
On 24/06/07, Al Mulnick wrote:
Do you have a software distribution method?
Al
On 6/24/07, Matheesha Weerasinghe
wrote:
The goldbuilds are given to onsite admins who can rebuild the machine if
deemed necessary. We allow them to jon the machines to the domain and they have
local admin rights on the machine (via the domain accounts). They dont need to
know the local admin password and neither do the users. Hence the period
recycling of passwords using the script.
M@
On 24/06/07, Al Mulnick wrote:
Seriously?
Why are you not able to set the local administrator password to an account you
want? You can rename it (so it's not human readable as administrator) and
set the password during the build process. You shouldn't build one without a
password - the default in Vista if I recall correctly.
On 6/24/07, Matheesha Weerasinghe < matheesha@gmail.com >
wrote:
Remote resetting with an app sounds very good. But the reason we use startup
scripts is to ensure the passwords get reset to the values we want after the
workstation is rebuilt and joined to the domain.
Other than adding the task of "resetting the password manually" to
the process of rebuilding a workstation, I cant think of any other way to
handle machine rebuilds from gold builds.
Any suggestions?
M@
On 24/06/07, Richard Kline > wrote:
We found that a
traditional VBS startup script was too insecure.The new password
was visible within a plain text or easily decrypted file.
I wrote a .net
application which remotely attaches to workstations and changes the local
administrator password. If you follow this route, I recommend that you
store the change attempt results (success or reason for failure) into a
database for control and management review.
From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 8:04 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] startup script local admin password reset
Hi All
Need help....
I do want to change local admin password of all computers in an example.com domain. I've made a
script that does work when run in a virtual environment using 1 dc windows
server 2003 and 1 windows xp sp2 client. I followed following steps when doing
the same:
1> made a test ou in my example.com
domain
2> made a gpo and configure startup script, provided share path of the
script and log file (the actions are logged in the same)
3> put 1 computer in the test ou
4> start the computer and it did work
the same thing i am trying to implement in my company's domain. for testing
i've made a test ou and put 5 computers there. created a gpo and provided the
share path of the script. but when the computer is started no script run. we're
running windows 2000 active directory domain, windows xp sp2 clients.
i've carried out some tests/facts which are as follows:
1> made a simple drive mapping script and put it in logon script. it does
work. it means gpo has applied on this test ou.
2> put admin password change script in the same shared folder and put it in
startup script. but it doesn't work.
3> working in a multiple dcs environment, and using the dc which lies in the
computers site on which testing is carried out.
Please let me know if you require further information in this regards. I do
want to implement the same in our domain which would save a lot of time and
will automate the activity.
Thanks in advance...
--
Regards
Anuj Attree
This message may contain confidential information and is intended only for
the individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
This message may contain
confidential information and is intended only for the individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| austin
Posts:8
|
|