| Author | Messages | |
matheesha
Posts:14
 | | 06/24/2007 8:32 AM |
| oops the query was wrong! I meant (objectcategory=computer)(cn=) and attr xxx-localadmin where xxx-localadmin is a custom attribute and the is retrieved from local env variables. I know its obvious but just adding for clarity.
On 24/06/07, Matheesha Weerasinghe wrote:
I am not a strong scripter and neither am I a coder. I was wondering of doing something like this.
Each computer stores its local admin password in AD in an attribute. Could create one or use an attribute deemed suitable for this.
The attribute must be ACLd to ensure only the computer account or domain computers group can read the attribute and a chosen admin group can read and write to the attribute.
Do a batch update of the attribute across the estate. You can have different computers with different values for local admin password. (perhaps based on geographical location, dept?)
The script or tool that runs on each computer is defined in GPO startup scripts. It does a query for the attribute (objectcategory=computer)(xxx-localadmin). The query is done using kerberos encryption (ldap_opt_encrypt). Therefore the network trace shouldnt show something legible.
Use the value as the parameter to reset local admin
Just need to script/code it now ;-)
M@
On 24/06/07, Bart Van den Wyngaert > wrote:
I'm very interested in this... Actually if you're able to or encrupt the password properly or have a routine to retrieve a password from a safe location you should be set, right? I'm looking myself for such a way of working for certain scripts, but I haven't found it out yet. Let me know if somebody knows an interesting way of working with sufficient security.
Thanks
On 6/24/07, Matheesha Weerasinghe > 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 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 | | | |
| SteveRochford
Posts:10
| | 06/24/2007 8:35 AM |
| If you put the script on a share which can be read by “domain
computer” but not by “domain users”, does that lessen the risk?
Steve
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Brian Desmond
Sent: 24 June 2007 01:19
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
You do realize that by putting this script out there anyone and
everyone in your domain can just go look at the script and write the password
down right?
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7: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 | | | |
| amulnick
Posts:138
| | 06/24/2007 9:30 AM |
| 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 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 | | | |
| amulnick
Posts:138
| | 06/24/2007 9:47 AM |
| Not really. It's about the context you run the account under. Typically you're looking for reasonable levels of security when you try and protect something of value. In the case of a password like that, you have no way to both protect and distribute the password based on the security contexts readily available. As joe pointed out, if you have physical access to a machine, you as the stake holder (in the protected information) have no reasonable expectation of privacy and protection. Any script kiddie could gain the administrator password on a machine they physically have access to. And to run as the local computer security context is not that tough either. That's akin to writing your password on a piece of paper and putting it under your desktop monitor - it keeps out the casual passer-by, but anyone slightly more awake or interested has free access.
What you need is a separate way to change the password that's more of a pull method than a push. Kind of what was happening with startup scripts but taken to the next level.I asked earlier about software distribution. Why? Because that usually has a way to install software under an elevated security context. And because it runs under an account that uses domain credentials, you have other issues to worry about if somebody cracks that password. But you'll know that if a local machine goes missing, that even if they can reset that local administrator password and even if they can reset that agent password, that won't compromise the remainder of the agents and computers.
Software distribution is usually an agent-based topology which can be told to wake up, pull down x package, and install it under y credentials. In a large, diverse and challenged network, that can help to address the issues with network latency, machines that are turned off (get it when it comes back on?) or machines that are home or on extended leave from the network (when they connect remotely - you can control that behavior). It also let's you better control the state of your machines, but that's a different discussion.
You could send a package that wakes up and pulls the new password from a central place, running as the credential of the service account that runs the agent (use domain credentials). Results can be sent back to the controlling mechanism.
-ajmOn 6/24/07, Bart Van den Wyngaert wrote:
I'm very interested in this... Actually if you're able to or encrupt the password properly or have a routine to retrieve a password from a safe location you should be set, right? I'm looking myself for such a way of working for certain scripts, but I haven't found it out yet. Let me know if somebody knows an interesting way of working with sufficient security.
Thanks
On 6/24/07, Matheesha Weerasinghe > 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 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 | | | |
| matheesha
Posts:14
| | 06/24/2007 10:21 AM |
| 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 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 | | | |
| MThommes
Posts:74
| | 06/24/2007 10:33 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
This article
from the Microsoft Certified Professionals Magazine might also be of interest
to you:
http://mcpmag.com/columns/article.asp?EditorialsID=1523
Mike Thommes
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7:28
PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup
script local admin password reset
This would be a startup script and would run when computers logged into
domain. Some kind of security permissions can be assigned so that only computer
a/cs logging inwould be able to read and execute the same. I am not much
sure about this and would carry out further tests before implementation.
If you'vea bettersolution, i would really appreciate if
youshare the same with me.
Regards,
Anuj Attree
On 6/24/07, Brian
Desmond
wrote:
You do realize that by
putting this script out there anyone and everyone in your domain can just go
look at the script and write the password down right?
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7: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
--
Regards
Anuj Attree | | | |
| listmail
Posts:454
| | 06/24/2007 11:09 AM |
| > And by the way, they don't have the ability to
schedule tasks or install services. Also, users are not able to install any s/w
without IT approval.
Is
this a "for certain" or is this, we tried our best and we think we got it? I
expect the later as the former is pretty darn near impossible to achieve without
basically installing root kits that you control and they interrogate every
single system request. Windows machines, and many OSes honestly, aren't meant to
truly and completely protect against the person sitting right there in front of
the machine; especially once they have admin creds. They are like Al mentioned,
something that will stop the casual passer by but if someone is serious, they
will bypass it. Once someone has admin level access on a machine they can pretty
much dig into anything you do and it is very difficult if not impossible to stop
them.
On the
positive side, this means you have kept the password out of the casual users
(and programs)which likely will account for 99%+ of your environment. On
the negative side, you aren't keeping it away from the people who are intent on
getting it and those are the people you need to be afraid of in the first place.
Using
a logon script to change a password, you have several key vectors you have to
consider.
1.
Someone can read the password in the clear as it comes across the wire. This can
be done by installing software on the local machine or it can be done by putting
the computer on a hub and putting another you don't control on the hub and
having it watch the network traffic. The only way to protect against this is to
make sure there is never any traffic "in the clear" with the password(s)
involved.
2.
Someone can impersonate the computer with local system or network service
accounts and go to the GPO and read the password directly.The only way to
protect against this is to make sure that the password isn't stored "in the
clear" anywhere that the computer can read it.
3.
Someone could run software that knows how to use debugger rights and can pick
the logon script right out of the GPO process. Sort of a more technical way
ofdoing 1 and 2 BUT if they are here, they can also see the password as it
is decrypted or whatever to set it because you need a clear text password to set
the password.
4.
Someone can intercept the password change on the machine with a password change
notification package DLL. With almost all systems this is pretty much game over
if someone can do this and it only requires admin rights to do it and most
software monitoring packages that prevent users from running software DO NOT
even look at this type of attack. Password change notification filters are
trivial to write poorly and you only need a poorly written one to get the
password. Think about this every time someone releases an exploit thatis
an escalation exploit. Or if you let people run with creds that they can
escalate (like power users for example) or if you just let them run as admins.
5.
Someone can intercept the password change by hooking the password change API
calls directly, easier to do number 4 but still a vector to consider. Has same
capabilities of 4.
6.Someone can dump the password hash and attempt to
crack it. Oldie but goodie.
These
are just the ones I thought up off the top of my head quickly. If I really sat
down and put my noodle into it I could probably find some additional ways to
pull this off.
The
main thing to note is that these are 6 great reasons not to use a common
password across multiple machines. Once someone has the password, they own all
of the machines. Each machine should have a password specific to it. That way if
someone does compromise the system, they have the password only for that system.
This also means that you can't have the mechanism to generate the passwords so
it isn't visible through any of those mechanisms either or else someone has the
mechanism and that is likely going to be as good as having the passwords
themselves.
Now if
the person is simply into knowing the passwords on the local system they have
two additional vectors that I just thought of...
7.
Someone can use one of theseveral offline reset the admin account packages
to reset the password.
8.
Someone could use a password filter to reject the attempts to change that
password. This could also be handled by hooking the APIs.Again, this won't
require great code, just very simple code. I once wrote and sold a password
filter that was specifically for locking down the default admin account so
people couldn't SET the password, they had to know the old password and use
CHANGE to modify it. It simply was a case of looking at the RID, seeing it was
the well-known RID for admin and then rejecting all SET attempts.
Tools
that go out and force this change remotely are an option, but again, you will
note several of the items above will compromise this. Also this doesn't scale
all that well. Some form of agent is likely the best way of handling it and if
that agent can start prior to any compromise code (i.e. so it can look at the
password API function call addresses before they can be compromised) and
validate that no one has installed any password filters/change notification
packages you are almost there... Except for people who have debug rights and can
then watch for that agent to send the passwords into the password change API. Of
course at this point, the bar is pretty high because as we discussed previously,
not many people are into debugging apps. But again, that element you don't want
to have the password are probably the ones that do know how to debug. So again
it comes back to making sure you don't have the same password everywhere and
making sure the algorithm isn't available for the debugger to
see.
One
other thing to keep in mind if you go forward with logon scripts is that you
make sure you have some mechanism to feed back that a password has been changed.
Don't assume it has. Bad security precedent there.
In
summary, this is not in any shape or form a trivial problem to solve. If you
have someone who is determined to get your password and they have any ability to
learn Windows details they will figure out how to bypass pretty much anything
you can do. The main thing I try to remind everyone with security... You can
NEVER prove something secure, you can only prove it is insecure. Just because
you think it is secure simply means it is secure from you because you can't
think of a way around it... Someone else may and probably is better than you and
can get around it.This is the point that you have to do everything you can (and
makes sense) to mitigate the risks of a compromise. You mustunderstand
what the risks actually are so you can understand the level you should go to to
mitigate them.
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 Anuj
AttreeSent: Saturday, June 23, 2007 10:05 PMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script
local admin password reset
Hi Joe
Thanks for your concern...
I just want a way to do this task (like many others)automatically.
Scripting give me a hope. If there are security implications then i will find
and implement the same and only after that the solutionwould be in affect.
And by the way, they don't have the ability to schedule tasks or install
services. Also, users are not able to install any s/w without IT approval.
Right now i m not able to run this script and would request you all to
suggest a solutionwith securityconcerns.The solution/s could
be different but my objective is to automate this task.
On 6/24/07, joe
wrote:
Do the
users have the ability to schedule tasks or install services? If so, they can
easily get to the startup script.Can they run a network sniffer? If so,
they can easily get to the startup script.
Oh by the
way, if they have physical access to the workstations (and I expect they do)
and they have any real level of understanding they can do the things above
whether you think so or not.
--
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 Anuj
AttreeSent: Saturday, June 23, 2007 8:28 PM To: ActiveDir@mail.activedir.orgSubject: Re:
[ActiveDir] startup script local admin password reset
This would be a startup script and would run when computers logged into
domain. Some kind of security permissions can be assigned so that only
computer a/cs logging inwould be able to read and execute the same. I am
not much sure about this and would carry out further tests before
implementation.
If you'vea bettersolution, i would really appreciate if
youshare the same with me.
Regards,
Anuj Attree
On 6/24/07, Brian
Desmond > wrote:
You do realize that by
putting this script out there anyone and everyone in your domain can just go
look at the script and write the password down right?
Thanks,
Brian
Desmond
brian@briandesmond.com
c -
312.731.3132
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
Anuj AttreeSent: Saturday, June 23, 2007 7:04
PMTo: activedir@mail.activedir.orgSubject:
[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
--
RegardsAnuj Attree -- RegardsAnuj Attree | | | |
| matheesha
Posts:14
| | 06/25/2007 2:31 AM |
| 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 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 | | | |
| amulnick
Posts:138
| | 06/25/2007 3:30 AM |
| 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 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 | | | |
| matheesha
Posts:14
| | 06/25/2007 3:45 AM |
| 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 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 | | | |
| m weerasinghe
Posts:0
| | 06/25/2007 4:20 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Undoubtedly the discussion has been and is helpful. I regard everyone’s
input as invaluable. Especially noted experts such as you ;-)
M@
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 | | | |
| SteveRochford
Posts:10
| | 06/25/2007 5:46 AM |
| Don't you need local admin rights to do that? If you've got local admin rights then surely it doesn't matter about whether you can hack a password setting script - you've got complete control over the machine anyway??
Steve
________________________________
From: ActiveDir-owner@mail.activedir.org on behalf of Boswell, Richard
Sent: Sun 24/06/2007 22:05
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
It's even easier than that. Just reset the file association for *.vbs to Notepad and the script will open up whenever the GPO applies it. I used to do this when I was in Application Engineering to determine what the logon scripts did (and try to determine why it took so long to logon).
RPMEE (http://www.liebsoft.com/index.cfm/cms?id=270) is expensive but in the end which costs more? The software or the damage control?
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: Sunday, June 24, 2007 10:09 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
> And by the way, they don't have the ability to schedule tasks or install services. Also, users are not able to install any s/w without IT approval.
Is this a "for certain" or is this, we tried our best and we think we got it? I expect the later as the former is pretty darn near impossible to achieve without basically installing root kits that you control and they interrogate every single system request. Windows machines, and many OSes honestly, aren't meant to truly and completely protect against the person sitting right there in front of the machine; especially once they have admin creds. They are like Al mentioned, something that will stop the casual passer by but if someone is serious, they will bypass it. Once someone has admin level access on a machine they can pretty much dig into anything you do and it is very difficult if not impossible to stop them.
On the positive side, this means you have kept the password out of the casual users (and programs) which likely will account for 99%+ of your environment. On the negative side, you aren't keeping it away from the people who are intent on getting it and those are the people you need to be afraid of in the first place.
Using a logon script to change a password, you have several key vectors you have to consider.
1. Someone can read the password in the clear as it comes across the wire. This can be done by installing software on the local machine or it can be done by putting the computer on a hub and putting another you don't control on the hub and having it watch the network traffic. The only way to protect against this is to make sure there is never any traffic "in the clear" with the password(s) involved.
2. Someone can impersonate the computer with local system or network service accounts and go to the GPO and read the password directly.The only way to protect against this is to make sure that the password isn't stored "in the clear" anywhere that the computer can read it.
3. Someone could run software that knows how to use debugger rights and can pick the logon script right out of the GPO process. Sort of a more technical way of doing 1 and 2 BUT if they are here, they can also see the password as it is decrypted or whatever to set it because you need a clear text password to set the password.
4. Someone can intercept the password change on the machine with a password change notification package DLL. With almost all systems this is pretty much game over if someone can do this and it only requires admin rights to do it and most software monitoring packages that prevent users from running software DO NOT even look at this type of attack. Password change notification filters are trivial to write poorly and you only need a poorly written one to get the password. Think about this every time someone releases an exploit that is an escalation exploit. Or if you let people run with creds that they can escalate (like power users for example) or if you just let them run as admins.
5. Someone can intercept the password change by hooking the password change API calls directly, easier to do number 4 but still a vector to consider. Has same capabilities of 4.
6.Someone can dump the password hash and attempt to crack it. Oldie but goodie.
These are just the ones I thought up off the top of my head quickly. If I really sat down and put my noodle into it I could probably find some additional ways to pull this off.
The main thing to note is that these are 6 great reasons not to use a common password across multiple machines. Once someone has the password, they own all of the machines. Each machine should have a password specific to it. That way if someone does compromise the system, they have the password only for that system. This also means that you can't have the mechanism to generate the passwords so it isn't visible through any of those mechanisms either or else someone has the mechanism and that is likely going to be as good as having the passwords themselves.
Now if the person is simply into knowing the passwords on the local system they have two additional vectors that I just thought of...
7. Someone can use one of the several offline reset the admin account packages to reset the password.
8. Someone could use a password filter to reject the attempts to change that password. This could also be handled by hooking the APIs. Again, this won't require great code, just very simple code. I once wrote and sold a password filter that was specifically for locking down the default admin account so people couldn't SET the password, they had to know the old password and use CHANGE to modify it. It simply was a case of looking at the RID, seeing it was the well-known RID for admin and then rejecting all SET attempts.
Tools that go out and force this change remotely are an option, but again, you will note several of the items above will compromise this. Also this doesn't scale all that well. Some form of agent is likely the best way of handling it and if that agent can start prior to any compromise code (i.e. so it can look at the password API function call addresses before they can be compromised) and validate that no one has installed any password filters/change notification packages you are almost there... Except for people who have debug rights and can then watch for that agent to send the passwords into the password change API. Of course at this point, the bar is pretty high because as we discussed previously, not many people are into debugging apps. But again, that element you don't want to have the password are probably the ones that do know how to debug. So again it comes back to making sure you don't have the same password everywhere and making sure the algorithm isn't available for the debugger to see.
One other thing to keep in mind if you go forward with logon scripts is that you make sure you have some mechanism to feed back that a password has been changed. Don't assume it has. Bad security precedent there.
In summary, this is not in any shape or form a trivial problem to solve. If you have someone who is determined to get your password and they have any ability to learn Windows details they will figure out how to bypass pretty much anything you can do. The main thing I try to remind everyone with security... You can NEVER prove something secure, you can only prove it is insecure. Just because you think it is secure simply means it is secure from you because you can't think of a way around it... Someone else may and probably is better than you and can get around it.This is the point that you have to do everything you can (and makes sense) to mitigate the risks of a compromise. You must understand what the risks actually are so you can understand the level you should go to to mitigate them.
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 Anuj Attree
Sent: Saturday, June 23, 2007 10:05 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
Hi Joe
Thanks for your concern...
I just want a way to do this task (like many others) automatically. Scripting give me a hope. If there are security implications then i will find and implement the same and only after that the solution would be in affect.
And by the way, they don't have the ability to schedule tasks or install services. Also, users are not able to install any s/w without IT approval.
Right now i m not able to run this script and would request you all to suggest a solution with security concerns. The solution/s could be different but my objective is to automate this task.
On 6/24/07, joe wrote:
Do the users have the ability to schedule tasks or install services? If so, they can easily get to the startup script. Can they run a network sniffer? If so, they can easily get to the startup script.
Oh by the way, if they have physical access to the workstations (and I expect they do) and they have any real level of understanding they can do the things above whether you think so or not.
--
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 Anuj Attree
Sent: Saturday, June 23, 2007 8:28 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
This would be a startup script and would run when computers logged into domain. Some kind of security permissions can be assigned so that only computer a/cs logging in would be able to read and execute the same. I am not much sure about this and would carry out further tests before implementation.
If you've a better solution, i would really appreciate if you share the same with me.
Regards,
Anuj Attree
On 6/24/07, Brian Desmond wrote:
You do realize that by putting this script out there anyone and everyone in your domain can just go look at the script and write the password down right?
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7: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
--
Regards
Anuj Attree
--
Regards
Anuj Attree | | | |
| bwatson
Posts:28
| | 06/25/2007 9:56 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Here is the original article with a working link to the talked
about utility.
http://www.myitforum.com/articles/12/view.asp?id=8553
The one over at Techtarget had a dead link unfortunately.
Thanks,
Ben Watson
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Thommes, Michael M.
Sent: Sunday, June 24, 2007 4:38 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
You might want to check out this utility. I have not used it
but the source has always been a good resource for me:
http://searchwincomputing.techtarget.com/tip/0,289483,sid68_gci1083716,00.html
Mike Thommes
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7:28 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
This would be a startup script and would run when computers
logged into domain. Some kind of security permissions can be assigned so that
only computer a/cs logging inwould be able to read and execute the same.
I am not much sure about this and would carry out further tests before
implementation.
If you'vea bettersolution, i would really
appreciate if youshare the same with me.
Regards,
Anuj Attree
On 6/24/07, Brian Desmond wrote:
You do realize that by
putting this script out there anyone and everyone in your domain can just go
look at the script and write the password down right?
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7: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
--
Regards
Anuj Attree | | | |
| amulnick
Posts:138
| | 06/25/2007 12:18 PM |
| In this case it does matter. The OP was discussing setting all workstation administrator passwords to the same thing. If you get the password without changing it, you now have access to every machine that the script ran on.
It matters. On 6/25/07, Steve Rochford wrote:
Don't you need local admin rights to do that? If you've got local admin rights then surely it doesn't matter about whether you can hack a password setting script - you've got complete control over the machine anyway??
Steve________________________________From: ActiveDir-owner@mail.activedir.org on behalf of Boswell, RichardSent: Sun 24/06/2007 22:05
To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script local admin password resetIt's even easier than that. Just reset the file association for *.vbs to Notepad and the script will open up whenever the GPO applies it. I used to do this when I was in Application Engineering to determine what the logon scripts did (and try to determine why it took so long to logon).
RPMEE (http://www.liebsoft.com/index.cfm/cms?id=270) is expensive but in the end which costs more? The software or the damage control?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: Sunday, June 24, 2007 10:09 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script local admin password reset
> And by the way, they don't have the ability to schedule tasks or install services. Also, users are not able to install any s/w without IT approval.Is this a "for certain" or is this, we tried our best and we think we got it? I expect the later as the former is pretty darn near impossible to achieve without basically installing root kits that you control and they interrogate every single system request. Windows machines, and many OSes honestly, aren't meant to truly and completely protect against the person sitting right there in front of the machine; especially once they have admin creds. They are like Al mentioned, something that will stop the casual passer by but if someone is serious, they will bypass it. Once someone has admin level access on a machine they can pretty much dig into anything you do and it is very difficult if not impossible to stop them.
On the positive side, this means you have kept the password out of the casual users (and programs) which likely will account for 99%+ of your environment. On the negative side, you aren't keeping it away from the people who are intent on getting it and those are the people you need to be afraid of in the first place.
Using a logon script to change a password, you have several key vectors you have to consider.1. Someone can read the password in the clear as it comes across the wire. This can be done by installing software on the local machine or it can be done by putting the computer on a hub and putting another you don't control on the hub and having it watch the network traffic. The only way to protect against this is to make sure there is never any traffic "in the clear" with the password(s) involved.
2. Someone can impersonate the computer with local system or network service accounts and go to the GPO and read the password directly.The only way to protect against this is to make sure that the password isn't stored "in the clear" anywhere that the computer can read it.
3. Someone could run software that knows how to use debugger rights and can pick the logon script right out of the GPO process. Sort of a more technical way of doing 1 and 2 BUT if they are here, they can also see the password as it is decrypted or whatever to set it because you need a clear text password to set the password.
4. Someone can intercept the password change on the machine with a password change notification package DLL. With almost all systems this is pretty much game over if someone can do this and it only requires admin rights to do it and most software monitoring packages that prevent users from running software DO NOT even look at this type of attack. Password change notification filters are trivial to write poorly and you only need a poorly written one to get the password. Think about this every time someone releases an exploit that is an escalation exploit. Or if you let people run with creds that they can escalate (like power users for example) or if you just let them run as admins.
5. Someone can intercept the password change by hooking the password change API calls directly, easier to do number 4 but still a vector to consider. Has same capabilities of 4.6.Someone can dump the password hash and attempt to crack it. Oldie but goodie.
These are just the ones I thought up off the top of my head quickly. If I really sat down and put my noodle into it I could probably find some additional ways to pull this off.The main thing to note is that these are 6 great reasons not to use a common password across multiple machines. Once someone has the password, they own all of the machines. Each machine should have a password specific to it. That way if someone does compromise the system, they have the password only for that system. This also means that you can't have the mechanism to generate the passwords so it isn't visible through any of those mechanisms either or else someone has the mechanism and that is likely going to be as good as having the passwords themselves.
Now if the person is simply into knowing the passwords on the local system they have two additional vectors that I just thought of...7. Someone can use one of the several offline reset the admin account packages to reset the password.
8. Someone could use a password filter to reject the attempts to change that password. This could also be handled by hooking the APIs. Again, this won't require great code, just very simple code. I once wrote and sold a password filter that was specifically for locking down the default admin account so people couldn't SET the password, they had to know the old password and use CHANGE to modify it. It simply was a case of looking at the RID, seeing it was the well-known RID for admin and then rejecting all SET attempts.
Tools that go out and force this change remotely are an option, but again, you will note several of the items above will compromise this. Also this doesn't scale all that well. Some form of agent is likely the best way of handling it and if that agent can start prior to any compromise code (
i.e. so it can look at the password API function call addresses before they can be compromised) and validate that no one has installed any password filters/change notification packages you are almost there... Except for people who have debug rights and can then watch for that agent to send the passwords into the password change API. Of course at this point, the bar is pretty high because as we discussed previously, not many people are into debugging apps. But again, that element you don't want to have the password are probably the ones that do know how to debug. So again it comes back to making sure you don't have the same password everywhere and making sure the algorithm isn't available for the debugger to see.
One other thing to keep in mind if you go forward with logon scripts is that you make sure you have some mechanism to feed back that a password has been changed. Don't assume it has. Bad security precedent there.
In summary, this is not in any shape or form a trivial problem to solve. If you have someone who is determined to get your password and they have any ability to learn Windows details they will figure out how to bypass pretty much anything you can do. The main thing I try to remind everyone with security... You can NEVER prove something secure, you can only prove it is insecure. Just because you think it is secure simply means it is secure from you because you can't think of a way around it... Someone else may and probably is better than you and can get around
it.This is the point that you have to do everything you can (and makes sense) to mitigate the risks of a compromise. You must understand what the risks actually are so you can understand the level you should go to to mitigate them.
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 Anuj Attree
Sent: Saturday, June 23, 2007 10:05 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script local admin password resetHi Joe
Thanks for your concern...I just want a way to do this task (like many others) automatically. Scripting give me a hope. If there are security implications then i will find and implement the same and only after that the solution would be in affect.
And by the way, they don't have the ability to schedule tasks or install services. Also, users are not able to install any s/w without IT approval.Right now i m not able to run this script and would request you all to suggest a solution with security concerns. The solution/s could be different but my objective is to automate this task.
On 6/24/07, joe wrote:Do the users have the ability to schedule tasks or install services? If so, they can easily get to the startup script. Can they run a network sniffer? If so, they can easily get to the startup script.
Oh by the way, if they have physical access to the workstations (and I expect they do) and they have any real level of understanding they can do the things above whether you think so or not.--
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 Anuj AttreeSent: Saturday, June 23, 2007 8:28 PMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script local admin password resetThis would be a startup script and would run when computers logged into domain. Some kind of security permissions can be assigned so that only computer a/cs logging in would be able to read and execute the same. I am not much sure about this and would carry out further tests before implementation.
If you've a better solution, i would really appreciate if you share the same with me.Regards,Anuj AttreeOn 6/24/07, Brian Desmond <
brian@briandesmond.com > wrote:You do realize that by putting this script out there anyone and everyone in your domain can just go look at the script and write the password down right?
Thanks,Brian Desmondbrian@briandesmond.comc - 312.731.3132
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Anuj Attree
Sent: Saturday, June 23, 2007 7:04 PMTo: activedir@mail.activedir.orgSubject: [ActiveDir] startup script local admin password reset
Hi AllNeed help....I do want to change local admin password of all computers in an example.com <
http://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--RegardsAnuj Attree--RegardsAnuj Attree | | | |
| amulnick
Posts:138
| | 06/25/2007 12:18 PM |
| 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 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 | | | |
| listmail
Posts:454
| | 06/26/2007 1:55 AM |
| v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
@font-face {
font-family: Wingdings;
}
@font-face {
font-family: Cambria Math;
}
@font-face {
font-family: Calibri;
}
@font-face {
font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 72.0pt 72.0pt 72.0pt; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.gmailquote {
mso-style-name: gmail_quote
}
SPAN.sg {
mso-style-name: sg
}
SPAN.e {
mso-style-name: e
}
SPAN.EmailStyle21 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
mso-style-type: export-only
}
DIV.Section1 {
page: Section1
}
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.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 cant 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. | |
|
|