| Author | Messages | |
amulnick
Posts:163
 | | 06/26/2007 12:07 PM |
| You work in an environment where building a workstation can be faster and more economical to just rebuild it. I envy that. I do not currently work in such an environment. Not my choice (where I work is my choice, but I do not control the helpdesk nor do I control the desktop environment to that level.) There are times when using the local administrator to troubleshoot is a necessary and useful method. Also much faster to resolve some issues than rebuilding. 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.
My point is that it is not always practical nor advised to use domain credentials only. By exception? Certainly. Exclusively? No. Having a process where each local administrator account is a) changed and b) unique to that machine mitigates the risk that I'm going to have my machines compromised by rogue administrators (very real risk here - not in my sphere of control) or that somebody will casually use the administrator account to do something to themselves and possibly others. Also mitigates virus propagation vectors because of the isolation. Also a very real threat in my environment.
Defining the requirements is critical to this because you have to be able to way the risk/effort in order to figure out if it is worth it in your environment. My $0.04 anyway (have to adjust for conversion :)
On 6/26/07, Austin Osuide wrote:
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:49
| | 06/27/2007 5:01 AM |
| Ok Al,
I submit :-)
The way I see it is we are both right. In a way. For Desktops that are always connected to the LAN and to which I can easily get a body, if I could have my way, I would disable the local admin account.
For laptops and mobile users, this presents a problem but that's what OU's & GPO's are for.
Interesting topic nonetheless and I'm sure it will continue to present nightmares and huge costs to companies who try to get a tight rein on local admin accounts.
Regards,
Austin
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 27 June 2007 17:25
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
I read that differently. I normally have strong
disagreements with putting Microsoft and Security in the same sentence
and often that means I strongly disagree with JesperJ and SteveR
In this case he advocates disabling the administrator account over
letting people obscure their access (there's that word again) by using
the local administrator account. I totally and wholeheartedly agree
that users should not be allowed to use the local administrator
account. That's not what it's for. They should not know the password.
It would help if they could go about their daily lives and install
drivers without that kind of access or without the password. It
doesn't work that way in the real world though I tend to partially
agree with JesperJ on this one - don't give your users the local
administrator password.
He goes on to cover that assertion by saying that if you cannot, then
at least make the password's different. He must have been oxygen
starved though, because later he goes back and says that if you don't
make them all unique and long (hard to guess), make them blank.
Like I said and like some others have echoed, removing the local
administrative creds is not feasible in reality. Maybe in Microsoft,
but not in any of their customers I've seen. the larger the
environment, the more likely this would be a method of access for
support in some situations. Not pretty nor perfect, but then I read
the blog differently too.
Al
On 6/27/07, Austin Osuide wrote:
>
>
>
>
> Absolutely Joe.
>
> But I think Al was referring to "security by obscurity" which is definitely
> not what I mean to put across here.
>
> Just did a google to see if I was alone here (even though I think you said
> you agreed with the concept) and found this by Jasper Johansson, formerly of
> MS STU:
>
> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> and thought I should share it. Quick and interesting reading it makes.
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> joe
> Sent: 27 June 2007 03:54
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
>
> obfuscating = to make obscure
>
>
>
> :)
>
>
>
> Until such a time that machines can be joined to a domain without the need
> for administrative credentials on the machine itself, local admin creds are
> likely going to be needed at some point for some reason. Period. There are
> times, I am not going to enumerate them, that shit happens and you fall back
> to local creds. This is experience from doing some form of support over the
> last 10 years in many companies with total seats across all numbering into
> the millions of seats and indirectly helping people with this kind of stuff
> through joeware/newsgroups likely into the tens of millions of seats (CPAU
> for instance is extremely popular in the Novell world as well as the MSFT
> world). This is simply reality. I will rail against reality on a fairly
> regular basis, anyone who has seen me rant against LDAPS or running ADI DNS
> on a Domain Controller has seen me do it, but this issue with local admin
> accounts is so big and so ever present in every org I have ever helped with
> any level of client assistance that it is just not worth the energy to rail
> against. It for intents and purposes is one of the true unwinnable battles.
> IF and this is a big IF I could join a machine to a domain without having
> any local creds on the box at all, like a push button on the GINA that said
> add to the domain I specify when I specify it and it cannot fail then local
> creds are not a big deal. Until that day, it is.
>
>
>
>
>
>
> --
>
> 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 8:10 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> There is no obscurity here Al.
>
> For a standalone machine, you will need the local admin cred for elevated
> privileges.
>
> For a machine that's joined to the domain, domain managed accounts have are
> given these privilages by default. You can further modify which domain creds
> have this level of access. (PS, I know you know and I'm not trying to teach
> you to suck eggs, just makes the point)
>
> The issue becomes relevant when the number of domain joined machines
> increases to the point where, to prevent dependencies in the security levels
> of machines the local admin passwords have to be different. In this
> scenario, your reliance on these creds decreases your security posture.
> Keeping the passwords different, available and changed at a regular
> interval, preferably after every audited request for the cred, is an
> overhead which with good planning, you can well do without.
>
>
>
> And, somehow, I have managed to work quite happily with restricted
> privileges "as far back" as the XP days J my privileges are elevated only
> when I need to. Vista just makes this more routine with less configuration
> from me and I quite like it. Yes, I've had some hang-ups but I've been able
> to resolve them most times by talking to the dev guys if I can find them or
> waiting till mass effect of demand causes a change (happens you know!).
> Giving users local admin effectively gives you no control over that box any
> more if the user so wishes. To cause you harm, all they'd need is access to
> google.
>
>
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
> Mulnick
> Sent: 27 June 2007 00:47
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
>
>
> 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.
>
> Al
>
>
>
>
> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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 could
> mean 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 saying many
> 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 the local admin password for a given
> machine whenever it is needed. Also from what I understand, that tends to
> get used on a fairly 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 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.
> ________________________________
>
>
>
> ________________________________
>
>
> 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.
>
> ________________________________
>
>
>
>
>
.+w֧B+v*rz+v*k}
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.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| austin
Posts:49
| | 06/27/2007 6:05 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Absolutely Joe.
But I think Al was referring to “security by obscurity”
which is definitely not what I mean to put across here.
Just did a google to see if I was alone here (even though I think
you said you agreed with the concept) and found this by Jasper Johansson, formerly
of MS STU:
http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
and thought I should share it. Quick and interesting reading it makes.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: 27 June 2007 03:54
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
obfuscating= to make obscure
:)
Until such a time that machines can be joined to a domain without
the need for administrative credentials on the machine itself, local admin
creds are likely going to be needed at some point for some reason. Period. There
are times, I am not going to enumerate them, thatshit happens and
youfall back to local creds. This is experience from doing some form of
support over the last 10 years inmany companies with total seats across
all numbering into the millions of seats and indirectly helping people with
this kind of stuff through joeware/newsgroups likely into the tens of millions
of seats (CPAU for instance is extremely popular in the Novell world as well as
the MSFT world). This is simply reality. I will rail against reality on a
fairly regular basis, anyone who has seen me rant against LDAPS or
running ADI DNS on a Domain Controller has seen me do it, but this issue with
local admin accounts is so big and so ever present in every org I have ever
helped with any level of client assistance that it is just not worth the energy
to rail against. It for intents and purposes is one of the true unwinnable
battles. IF and this is a big IF I could join a machine to a domain without
having any local creds on the box at all, like a push button on the GINA that
said add to the domain I specify when I specify it and it cannot fail then
local creds are not a big deal. Until that day, it is.
--
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 8:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
There is no obscurity here Al.
For a standalone machine, you will need the local admin cred for
elevated privileges.
For a machine that’s joined to the domain, domain managed
accounts have are given these privilages by default. You can further modify
which domain creds have this level of access. (PS, I know you know and
I’m not trying to teach you to suck eggs, just makes the point)
The issue becomes relevant when the number of domain joined
machines increases to the point where, to prevent dependencies in the security
levels of machines the local admin passwords have to be different. In this
scenario, your reliance on these creds decreases your security posture. Keeping
the passwords different, available and changed at a regular interval,
preferably after every audited request for the cred, is an overhead which with
good planning, you can well do without.
And, somehow, I have managed to work quite happily with
restricted privileges “as far back” as the XP days J my
privileges are elevated only when I need to. Vista just makes this more routine
with less configuration from me and I quite like it. Yes, I’ve had some
hang-ups but I’ve been able to resolve them most times by talking to the
dev guys if I can find them or waiting till mass effect of demand causes a
change (happens you know!). Giving users local admin effectively gives you no
control over that box any more if the user so wishes. To cause you harm, all
they’d need is access to google.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 27 June 2007 00:47
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
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.
Al
On 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.
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. | | | |
| listmail
Posts:824
| | 06/27/2007 11:57 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.q {
mso-style-name: q
}
SPAN.e {
mso-style-name: e
}
SPAN.EmailStyle21 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle22 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
page: Section1
}
Yep, I agree with the concept but don't think it is
feasible right now.
Jesper is a good smart guy, but I don't agree with
everything he says. We differ pretty well on Lockout and this idea of just
disabling the admin ID. If you create another admin ID locally on the machine,
sure disable the builtin but there should be a builtin ID until such a time that
we have what I described previously.
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: Wednesday, June 27, 2007 6:05 AMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script
local admin password reset
Absolutely
Joe.
But
I think Al was referring to security by obscurity which is definitely not what
I mean to put across here.
Just
did a google to see if I was alone here (even though I think you said you agreed
with the concept) and found this by Jasper Johansson, formerly of MS
STU:
http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
and thought I should share it. Quick and interesting reading it
makes.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of joeSent: 27 June 2007 03:54To:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script
local admin password reset
obfuscating=
to make obscure
:)
Until
such a time that machines can be joined to a domain without the need for
administrative credentials on the machine itself, local admin creds are likely
going to be needed at some point for some reason. Period. There are times, I am
not going to enumerate them, thatshit happens and youfall back to
local creds. This is experience from doing some form of support over the last 10
years inmany companies with total seats across all numbering into the
millions of seats and indirectly helping people with this kind of stuff through
joeware/newsgroups likely into the tens of millions of seats (CPAU for instance
is extremely popular in the Novell world as well as the MSFT world). This is
simply reality. I will rail against reality on a fairly regular basis, anyone
who has seen me rant against LDAPS or running ADI DNS on a Domain
Controller has seen me do it, but this issue with local admin accounts is so big
and so ever present in every org I have ever helped with any level of client
assistance that it is just not worth the energy to rail against. It for intents
and purposes is one of the true unwinnable battles. IF and this is a big IF I
could join a machine to a domain without having any local creds on the box at
all, like a push button on the GINA that said add to the domain I specify when I
specify it and it cannot fail then local creds are not a big deal. Until that
day, it is.
--
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 8:10
PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
startup script local admin password reset
There
is no obscurity here Al.
For
a standalone machine, you will need the local admin cred for elevated
privileges.
For
a machine thats joined to the domain, domain managed accounts have are given
these privilages by default. You can further modify which domain creds have this
level of access. (PS, I know you know and Im not trying to teach you to suck
eggs, just makes the point)
The
issue becomes relevant when the number of domain joined machines increases to
the point where, to prevent dependencies in the security levels of machines the
local admin passwords have to be different. In this scenario, your reliance on
these creds decreases your security posture. Keeping the passwords different,
available and changed at a regular interval, preferably after every audited
request for the cred, is an overhead which with good planning, you can well do
without.
And,
somehow, I have managed to work quite happily with restricted privileges as far
back as the XP days J my
privileges are elevated only when I need to. Vista just makes this more routine
with less configuration from me and I quite like it. Yes, Ive had some hang-ups
but Ive been able to resolve them most times by talking to the dev guys if I
can find them or waiting till mass effect of demand causes a change (happens you
know!). Giving users local admin effectively gives you no control over that box
any more if the user so wishes. To cause you harm, all theyd need is access to
google.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al MulnickSent: 27 June 2007 00:47To:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script
local admin password reset
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. Al
On 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
MulnickSent: 26 June 2007 22:43
To: ActiveDir@mail.activedir.orgSubject: 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, RichardSent: 26 June 2007 19:36
To: ActiveDir@mail.activedir.orgSubject: 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 joeSent:
Tuesday, June 26, 2007 1:27 PMTo: ActiveDir@mail.activedir.orgSubject: 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 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 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.
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.
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:163
| | 06/27/2007 12:25 PM |
| I read that differently. I normally have strong
disagreements with putting Microsoft and Security in the same sentence
and often that means I strongly disagree with JesperJ and SteveR
In this case he advocates disabling the administrator account over
letting people obscure their access (there's that word again) by using
the local administrator account. I totally and wholeheartedly agree
that users should not be allowed to use the local administrator
account. That's not what it's for. They should not know the password.
It would help if they could go about their daily lives and install
drivers without that kind of access or without the password. It
doesn't work that way in the real world though I tend to partially
agree with JesperJ on this one - don't give your users the local
administrator password.
He goes on to cover that assertion by saying that if you cannot, then
at least make the password's different. He must have been oxygen
starved though, because later he goes back and says that if you don't
make them all unique and long (hard to guess), make them blank.
Like I said and like some others have echoed, removing the local
administrative creds is not feasible in reality. Maybe in Microsoft,
but not in any of their customers I've seen. the larger the
environment, the more likely this would be a method of access for
support in some situations. Not pretty nor perfect, but then I read
the blog differently too.
Al
On 6/27/07, Austin Osuide wrote:
>
>
>
>
> Absolutely Joe.
>
> But I think Al was referring to "security by obscurity" which is definitely
> not what I mean to put across here.
>
> Just did a google to see if I was alone here (even though I think you said
> you agreed with the concept) and found this by Jasper Johansson, formerly of
> MS STU:
>
> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> and thought I should share it. Quick and interesting reading it makes.
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> joe
> Sent: 27 June 2007 03:54
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
>
> obfuscating = to make obscure
>
>
>
> :)
>
>
>
> Until such a time that machines can be joined to a domain without the need
> for administrative credentials on the machine itself, local admin creds are
> likely going to be needed at some point for some reason. Period. There are
> times, I am not going to enumerate them, that shit happens and you fall back
> to local creds. This is experience from doing some form of support over the
> last 10 years in many companies with total seats across all numbering into
> the millions of seats and indirectly helping people with this kind of stuff
> through joeware/newsgroups likely into the tens of millions of seats (CPAU
> for instance is extremely popular in the Novell world as well as the MSFT
> world). This is simply reality. I will rail against reality on a fairly
> regular basis, anyone who has seen me rant against LDAPS or running ADI DNS
> on a Domain Controller has seen me do it, but this issue with local admin
> accounts is so big and so ever present in every org I have ever helped with
> any level of client assistance that it is just not worth the energy to rail
> against. It for intents and purposes is one of the true unwinnable battles.
> IF and this is a big IF I could join a machine to a domain without having
> any local creds on the box at all, like a push button on the GINA that said
> add to the domain I specify when I specify it and it cannot fail then local
> creds are not a big deal. Until that day, it is.
>
>
>
>
>
>
> --
>
> 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 8:10 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> There is no obscurity here Al.
>
> For a standalone machine, you will need the local admin cred for elevated
> privileges.
>
> For a machine that's joined to the domain, domain managed accounts have are
> given these privilages by default. You can further modify which domain creds
> have this level of access. (PS, I know you know and I'm not trying to teach
> you to suck eggs, just makes the point)
>
> The issue becomes relevant when the number of domain joined machines
> increases to the point where, to prevent dependencies in the security levels
> of machines the local admin passwords have to be different. In this
> scenario, your reliance on these creds decreases your security posture.
> Keeping the passwords different, available and changed at a regular
> interval, preferably after every audited request for the cred, is an
> overhead which with good planning, you can well do without.
>
>
>
> And, somehow, I have managed to work quite happily with restricted
> privileges "as far back" as the XP days J my privileges are elevated only
> when I need to. Vista just makes this more routine with less configuration
> from me and I quite like it. Yes, I've had some hang-ups but I've been able
> to resolve them most times by talking to the dev guys if I can find them or
> waiting till mass effect of demand causes a change (happens you know!).
> Giving users local admin effectively gives you no control over that box any
> more if the user so wishes. To cause you harm, all they'd need is access to
> google.
>
>
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
> Mulnick
> Sent: 27 June 2007 00:47
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
>
>
> 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.
>
> Al
>
>
>
>
> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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 could
> mean 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 saying many
> 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 the local admin password for a given
> machine whenever it is needed. Also from what I understand, that tends to
> get used on a fairly 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 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.
> ________________________________
>
>
>
> ________________________________
>
>
> 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.
>
> ________________________________
>
>
>
>
>
.+-� 0�����j�q.+-� 0����ˊ�E��Kj�!i�b��b����ןj�m | | | |
| amulnick
Posts:163
| | 06/28/2007 3:36 AM |
| Some companies don't use change control in favor of "putting it in and
trying it out."
Some companies have it like that.
They'd burn the CTO's at this company in effigy and hang them from the
nearest yardarm the first time they went on the road (40% of the org
is mobile) and couldn't print a document or use the usb memory stick
that was company provided didn't work because of access rights. Or
couldn't get on the hotel's wireless network because their card fried
and they were unable to borrow one from the front desk. That's
prohibitive and not what IT is about in my opinion.
Users don't just deal in a company. They get somebody who can do the
job. They expect to have their expectations set and met on a regular
basis.
Will they put up with some oddities? Yes. Not being able to work? Nope.
Oh, nice to see that the company you describe is able to provide
printers for their workers that meet all the workers needs, including
those that travel more than 60% of the time. That's pretty cool
although not the norm from the companies I've seen.
Small company mistake with permissions - 1 day of outage while you go
around and fix it and propagate the fix.
Extra Large company mistake with permissions - 3 weeks outage while
you diagnose, fix and prevent from happening again while fix
propagates.
There's a difference Susan. It can be large.
In a multinational company where you're constantly
hiring/firing/expanding/contracting/outsourcing/insourcing you cannot
account for every change. You cannot make them purchase the same
hardware everywhere because in some countries you can't get that
hardware. Ship it you say? Go for it says I. Let me know how that
customs agent likes his son's new
printers and hardware. Size makes no difference on that scenario.
There could be 20 people in the company in 20 countries and you'd have
that issue.
If you're not a gummint agency, then you don't have unlimited
resources. You have to make a choice between users with local admin
rights or spending 500.00 (USD) per user to provide uniform equipment
- and it has to meet every need they can dream up because you cannot
possibly manage all the exceptions manually.
In your scenario below - their network card is the only one that
touches their network. Ok. I get that. Works for me. But when that
user travels, that card had better work elsewhere. To not deploy a
workable solution invites users and local staff to use workarounds.
Those suck even more and cause even more work as you try to prevent
that and then lose arguments with senior leaders that insist that it
is far more important to make money for the company than to prevent
that user from working because you don't have a good enough solution
for them to work.
It's not a tough issue to understand, but as you can see there are a
lot of different approaches. In fact, most companies have their own
unique blend of solutions to work with these issues. Some are more
acceptable to me than others, but I think that they all have their
reasons and all seem to understand why the issues exist.
Until there's a good way to ensure that those remote users can operate
without IT support, I have no better way to give them other than
administrative access in this particular environment. In a security
sensitive environment, where security takes precedence over work and
income (read that as the risk of compromise outweighs the lost
productivity) I can see doing what your friend lives with. When the
risk/reward goes the other way, then so does the solution.
On 6/28/07, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
wrote:
> A bit USA centric post.. apologies.
>
> Friend works for a large firm that does a lot of contract work for a
> certain.... Uncle.... Sam.
> She gets a laptop.
> She gets handed a wireless card.
> She gets handed a printer if they deem her printerworthy.
> She gets a build that includes PDF writers.
> She thought it was dumb when they deployed USB memory sticks and the
> encryption software for the usb had to be enabled/installed only with
> administrator rights on the laptop... yeah that caused quite a few help
> desk calls.
>
> Does she have admin rights? Nope.
> Can she add drivers when she's in a hotel? Nope.
> Print to the hotel printer? No way.
> Borrow someone's wireless card if she forgot hers? Nope. Sorry... only
> that card(s) can connect to their network.
> Does she sometimes have to live with her limitations? All the time.
> But she deals.
>
>
> But to say that "the larger the environment the more the need for local
> admin rights?"... I'm not sure I buy that.
>
> In big firms they "deploy" an image. If someone needs a new build it's
> ghosted/imaged out to the person. If the icons moved and the end user
> can't move icons, make a cutesy screensaver? Tough. The end users deal.
>
> I don't buy it that I can feasibly do it and you can't.
>
> Oh yeah.. and that firm I"m talking about... their help desk has to be
> USA based... no outsourced help desk either.
>
> joe wrote:
> > What happens if something happens and for whatever reason the machine just can't communicate with the domain? Just slam the machine with a new load and hope it works without ever even trying to log in and notice that someone dorked some DNS settings or something so it won't logon to the domain or something like that? Or are you just assuming you are going to use one of the password hacking CDs and try to get in that way?
> >
> > I do agree that the users shouldn't have the local admin password. Personally I like to see users without any admin level access. I ran marketing and treasury users that way back in the '97 time frame o NT4 and it worked famously, the lowest TCO I have seen on workstations ever. They just didn't break, no one who wasn't qualified to work on them could change anything.
> >
> >
> > --
> > O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Austin Osuide
> > Sent: Wednesday, June 27, 2007 5:02 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] startup script local admin password reset
> >
> > Ok Al,
> > I submit :-)
> > The way I see it is we are both right. In a way. For Desktops that are always connected to the LAN and to which I can easily get a body, if I could have my way, I would disable the local admin account.
> > For laptops and mobile users, this presents a problem but that's what OU's & GPO's are for.
> > Interesting topic nonetheless and I'm sure it will continue to present nightmares and huge costs to companies who try to get a tight rein on local admin accounts.
> >
> > Regards,
> >
> > Austin
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
> > Sent: 27 June 2007 17:25
> > To: ActiveDir@mail.activedir.org
> > Subject: Re: [ActiveDir] startup script local admin password reset
> >
> > I read that differently. I normally have strong
> > disagreements with putting Microsoft and Security in the same sentence
> > and often that means I strongly disagree with JesperJ and SteveR
> >
> >
> > In this case he advocates disabling the administrator account over
> > letting people obscure their access (there's that word again) by using
> > the local administrator account. I totally and wholeheartedly agree
> > that users should not be allowed to use the local administrator
> > account. That's not what it's for. They should not know the password.
> > It would help if they could go about their daily lives and install
> > drivers without that kind of access or without the password. It
> > doesn't work that way in the real world though I tend to partially
> > agree with JesperJ on this one - don't give your users the local
> > administrator password.
> >
> > He goes on to cover that assertion by saying that if you cannot, then
> > at least make the password's different. He must have been oxygen
> > starved though, because later he goes back and says that if you don't
> > make them all unique and long (hard to guess), make them blank.
> >
> > Like I said and like some others have echoed, removing the local
> > administrative creds is not feasible in reality. Maybe in Microsoft,
> > but not in any of their customers I've seen. the larger the
> > environment, the more likely this would be a method of access for
> > support in some situations. Not pretty nor perfect, but then I read
> > the blog differently too.
> >
> >
> > Al
> >
> >
> > On 6/27/07, Austin Osuide wrote:
> >
> >>
> >>
> >> Absolutely Joe.
> >>
> >> But I think Al was referring to "security by obscurity" which is definitely
> >> not what I mean to put across here.
> >>
> >> Just did a google to see if I was alone here (even though I think you said
> >> you agreed with the concept) and found this by Jasper Johansson, formerly of
> >> MS STU:
> >>
> >> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> >> and thought I should share it. Quick and interesting reading it makes.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Austin
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: ActiveDir-owner@mail.activedir.org
> >> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> >> joe
> >> Sent: 27 June 2007 03:54
> >>
> >> To: ActiveDir@mail.activedir.org
> >> Subject: RE: [ActiveDir] startup script local admin password reset
> >>
> >>
> >>
> >>
> >> obfuscating = to make obscure
> >>
> >>
> >>
> >> :)
> >>
> >>
> >>
> >> Until such a time that machines can be joined to a domain without the need
> >> for administrative credentials on the machine itself, local admin creds are
> >> likely going to be needed at some point for some reason. Period. There are
> >> times, I am not going to enumerate them, that shit happens and you fall back
> >> to local creds. This is experience from doing some form of support over the
> >> last 10 years in many companies with total seats across all numbering into
> >> the millions of seats and indirectly helping people with this kind of stuff
> >> through joeware/newsgroups likely into the tens of millions of seats (CPAU
> >> for instance is extremely popular in the Novell world as well as the MSFT
> >> world). This is simply reality. I will rail against reality on a fairly
> >> regular basis, anyone who has seen me rant against LDAPS or running ADI DNS
> >> on a Domain Controller has seen me do it, but this issue with local admin
> >> accounts is so big and so ever present in every org I have ever helped with
> >> any level of client assistance that it is just not worth the energy to rail
> >> against. It for intents and purposes is one of the true unwinnable battles.
> >> IF and this is a big IF I could join a machine to a domain without having
> >> any local creds on the box at all, like a push button on the GINA that said
> >> add to the domain I specify when I specify it and it cannot fail then local
> >> creds are not a big deal. Until that day, it is.
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> 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 8:10 PM
> >> To: ActiveDir@mail.activedir.org
> >> Subject: RE: [ActiveDir] startup script local admin password reset
> >>
> >> There is no obscurity here Al.
> >>
> >> For a standalone machine, you will need the local admin cred for elevated
> >> privileges.
> >>
> >> For a machine that's joined to the domain, domain managed accounts have are
> >> given these privilages by default. You can further modify which domain creds
> >> have this level of access. (PS, I know you know and I'm not trying to teach
> >> you to suck eggs, just makes the point)
> >>
> >> The issue becomes relevant when the number of domain joined machines
> >> increases to the point where, to prevent dependencies in the security levels
> >> of machines the local admin passwords have to be different. In this
> >> scenario, your reliance on these creds decreases your security posture.
> >> Keeping the passwords different, available and changed at a regular
> >> interval, preferably after every audited request for the cred, is an
> >> overhead which with good planning, you can well do without.
> >>
> >>
> >>
> >> And, somehow, I have managed to work quite happily with restricted
> >> privileges "as far back" as the XP days J my privileges are elevated only
> >> when I need to. Vista just makes this more routine with less configuration
> >> from me and I quite like it. Yes, I've had some hang-ups but I've been able
> >> to resolve them most times by talking to the dev guys if I can find them or
> >> waiting till mass effect of demand causes a change (happens you know!).
> >> Giving users local admin effectively gives you no control over that box any
> >> more if the user so wishes. To cause you harm, all they'd need is access to
> >> google.
> >>
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Austin
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: ActiveDir-owner@mail.activedir.org
> >> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
> >> Mulnick
> >> Sent: 27 June 2007 00:47
> >> To: ActiveDir@mail.activedir.org
> >> Subject: Re: [ActiveDir] startup script local admin password reset
> >>
> >>
> >>
> >> 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.
> >>
> >> Al
> >>
> >>
> >>
> >>
> >> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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 could
> >> mean 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 saying many
> >> 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 the local admin password for a given
> >> machine whenever it is needed. Also from what I understand, that tends to
> >> get used on a fairly 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 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.
> >> ________________________________
> >>
> >>
> >>
> >> ________________________________
> >>
> >>
> >> 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.
> >>
> >> ________________________________
> >>
> >>
> >>
> >>
> >>
> >>
> > .+wÖ§ B +v* r z +v* k}
> >
> > 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.
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
> >
> >
>
> --
> If you are a SBSer... you had better be reading http://blogs.technet.com/sbs - the SBS Blog.
>
> ..and my blog is at www.sbsdiva.com....
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
.+-� 0�����j�q.+-� 0����ˊ�E��Kj�!i�b��b����ןj�m | | | |
| amulnick
Posts:163
| | 06/28/2007 3:38 AM |
| If I had a nickel for every time that was true.....
On 6/28/07, joe wrote:
>
>
> resend
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
> ________________________________
> From: joe [mailto:listmail@joeware.net]
> Sent: Thursday, June 28, 2007 8:24 AM
> To: 'activedir@activedir.org'
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
> Ah good luck, getting feedback from the people doing the real work on
> clients in an environment of that size is difficult to almost impossible. I
> was just out on the US west coast at one of the smaller companies I deal
> with with only about 55k or so people and the client people at corporate
> said things were done one way and when I was out in a plant where the boots
> meets the concrete they were using the machines and IDs in a completely
> different way. Several local site folks all asked separately came up with
> the same answer. Then I spoke to the central people again and they were
> like, they absolutely are not doing it that way. I said "What if they are?".
> The answer was "That is a security issue?". I said... "Yes, I know".
> Basically the people in the field are not the greatest at getting feedback
> to corporate, they do whatever they feel they need to do to keep X rolling
> down the line because we build/sell/market X, not computers... In another
> example from last year, I walked into a place and was told there was no NT4,
> I did a scan over the IPs of supported machines, found over 100 NT4 domains
> and 300+ NT4 servers... None of it of course was in the datacenter, it was
> all out in branch/factory locations and the centralized people literally
> didn't have any idea it was out there. Over the years I have learned when
> walking into companies to listen to what corporate people tell me and then
> go figure out what is really being done.
>
>
> --
> 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: Thursday, June 28, 2007 6:17 AM
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
>
>
> I have taken it upon myself to find out how often in the last 6mo, in the
> 140k user env I currently work in, a local admin account has been used to
> "fix" an issue.
>
> I'll lt you know the feed-back I get.
>
>
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> joe
> Sent: 28 June 2007 04:57
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
> Yep, I agree with the concept but don't think it is feasible right now.
>
>
>
> Jesper is a good smart guy, but I don't agree with everything he says. We
> differ pretty well on Lockout and this idea of just disabling the admin ID.
> If you create another admin ID locally on the machine, sure disable the
> builtin but there should be a builtin ID until such a time that we have what
> I described previously.
>
>
>
> 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: Wednesday, June 27, 2007 6:05 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> Absolutely Joe.
>
> But I think Al was referring to "security by obscurity" which is definitely
> not what I mean to put across here.
>
> Just did a google to see if I was alone here (even though I think you said
> you agreed with the concept) and found this by Jasper Johansson, formerly of
> MS STU:
>
> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> and thought I should share it. Quick and interesting reading it makes.
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> joe
> Sent: 27 June 2007 03:54
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
> obfuscating = to make obscure
>
>
>
> :)
>
>
>
> Until such a time that machines can be joined to a domain without the need
> for administrative credentials on the machine itself, local admin creds are
> likely going to be needed at some point for some reason. Period. There are
> times, I am not going to enumerate them, that shit happens and you fall back
> to local creds. This is experience from doing some form of support over the
> last 10 years in many companies with total seats across all numbering into
> the millions of seats and indirectly helping people with this kind of stuff
> through joeware/newsgroups likely into the tens of millions of seats (CPAU
> for instance is extremely popular in the Novell world as well as the MSFT
> world). This is simply reality. I will rail against reality on a fairly
> regular basis, anyone who has seen me rant against LDAPS or running ADI DNS
> on a Domain Controller has seen me do it, but this issue with local admin
> accounts is so big and so ever present in every org I have ever helped with
> any level of client assistance that it is just not worth the energy to rail
> against. It for intents and purposes is one of the true unwinnable battles.
> IF and this is a big IF I could join a machine to a domain without having
> any local creds on the box at all, like a push button on the GINA that said
> add to the domain I specify when I specify it and it cannot fail then local
> creds are not a big deal. Until that day, it is.
>
>
>
>
>
>
> --
>
> 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 8:10 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> There is no obscurity here Al.
>
> For a standalone machine, you will need the local admin cred for elevated
> privileges.
>
> For a machine that's joined to the domain, domain managed accounts have are
> given these privilages by default. You can further modify which domain creds
> have this level of access. (PS, I know you know and I'm not trying to teach
> you to suck eggs, just makes the point)
>
> The issue becomes relevant when the number of domain joined machines
> increases to the point where, to prevent dependencies in the security levels
> of machines the local admin passwords have to be different. In this
> scenario, your reliance on these creds decreases your security posture.
> Keeping the passwords different, available and changed at a regular
> interval, preferably after every audited request for the cred, is an
> overhead which with good planning, you can well do without.
>
>
>
> And, somehow, I have managed to work quite happily with restricted
> privileges "as far back" as the XP days J my privileges are elevated only
> when I need to. Vista just makes this more routine with less configuration
> from me and I quite like it. Yes, I've had some hang-ups but I've been able
> to resolve them most times by talking to the dev guys if I can find them or
> waiting till mass effect of demand causes a change (happens you know!).
> Giving users local admin effectively gives you no control over that box any
> more if the user so wishes. To cause you harm, all they'd need is access to
> google.
>
>
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
> Mulnick
> Sent: 27 June 2007 00:47
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
>
>
> 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.
>
> Al
>
>
> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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 could
> mean 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 saying many
> 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 the local admin password for a given
> machine whenever it is needed. Also from what I understand, that tends to
> get used on a fairly 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 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.
> ________________________________
>
>
>
> ________________________________
>
>
> 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.
>
> ________________________________
>
>
>
>
>
>
>
.+-� 0�����j�q.+-� 0����ˊ�E��Kj�!i�b��b����ןj�m | | | |
| TG
Posts:312
| | 06/28/2007 3:52 AM |
| That is all fine, however...
As Joe said, so many times I was able
to login to a server with a local ID and fix the problem within 2-5 min.
It would have cost the company at least few hours to rebuild the
server, not to mention the app reinstalls. Some apps require the
vendor to do the re-install, there goes a few days of time and possibly
travel cost.
Not to mention, iirc, the recovery console
requires the 500 account to login.
Yes, sometimes, I also had to resort
to the boot CDs that Joe mentioned, as well. Would not want to hand
them down to the first level responders (I know they are available to whoever
is smart to enough to search google, I just do not want to be the distributor).
Thank you, Tony.
Tony Gordon, Windows 2003 & 2000 MCSE,
Windows 2003 MCSA
tony dot gordon at hewitt dot com
Windows Server Infrastructure
Phone: 847.295.5000 x14534
Fax: 847.295.8877
Hewitt
Associates
"Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]"
Sent by: ActiveDir-owner@mail.activedir.org
06/27/2007 11:16 PM
Please respond to
ActiveDir@mail.activedir.org
To
ActiveDir@mail.activedir.org
cc
Subject
Re: [ActiveDir] startup script local
admin password reset
A bit USA centric post.. apologies.
Friend works for a large firm that does a lot of contract work for a
certain.... Uncle.... Sam.
She gets a laptop.
She gets handed a wireless card.
She gets handed a printer if they deem her printerworthy.
She gets a build that includes PDF writers.
She thought it was dumb when they deployed USB memory sticks and the
encryption software for the usb had to be enabled/installed only with
administrator rights on the laptop... yeah that caused quite a few help
desk calls.
Does she have admin rights? Nope.
Can she add drivers when she's in a hotel? Nope.
Print to the hotel printer? No way.
Borrow someone's wireless card if she forgot hers? Nope. Sorry...
only
that card(s) can connect to their network.
Does she sometimes have to live with her limitations? All the time.
But she deals.
But to say that "the larger the environment the more the need for
local
admin rights?"... I'm not sure I buy that.
In big firms they "deploy" an image. If someone needs a
new build it's
ghosted/imaged out to the person. If the icons moved and the end
user
can't move icons, make a cutesy screensaver? Tough. The end
users deal.
I don't buy it that I can feasibly do it and you can't.
Oh yeah.. and that firm I"m talking about... their help desk has to
be
USA based... no outsourced help desk either.
joe wrote:
> What happens if something happens and for whatever reason the machine
just can't communicate with the domain? Just slam the machine with a new
load and hope it works without ever even trying to log in and notice that
someone dorked some DNS settings or something so it won't logon to the
domain or something like that? Or are you just assuming you are going to
use one of the password hacking CDs and try to get in that way?
>
> I do agree that the users shouldn't have the local admin password.
Personally I like to see users without any admin level access. I ran marketing
and treasury users that way back in the '97 time frame o NT4 and it worked
famously, the lowest TCO I have seen on workstations ever. They just didn't
break, no one who wasn't qualified to work on them could change anything.
>
>
> --
> O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide
> Sent: Wednesday, June 27, 2007 5:02 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> Ok Al,
> I submit :-)
> The way I see it is we are both right. In a way. For Desktops that
are always connected to the LAN and to which I can easily get a body, if
I could have my way, I would disable the local admin account.
> For laptops and mobile users, this presents a problem but that's what
OU's & GPO's are for.
> Interesting topic nonetheless and I'm sure it will continue to present
nightmares and huge costs to companies who try to get a tight rein on local
admin accounts.
>
> Regards,
>
> Austin
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
> Sent: 27 June 2007 17:25
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
> I read that differently. I normally have
strong
> disagreements with putting Microsoft and Security in the same sentence
> and often that means I strongly disagree with JesperJ and SteveR
>
>
> In this case he advocates disabling the administrator account over
> letting people obscure their access (there's that word again) by using
> the local administrator account. I totally and wholeheartedly
agree
> that users should not be allowed to use the local administrator
> account. That's not what it's for. They should not know the
password.
> It would help if they could go about their daily lives and install
> drivers without that kind of access or without the password. It
> doesn't work that way in the real world though I tend to partially
> agree with JesperJ on this one - don't give your users the local
> administrator password.
>
> He goes on to cover that assertion by saying that if you cannot, then
> at least make the password's different. He must have been oxygen
> starved though, because later he goes back and says that if you don't
> make them all unique and long (hard to guess), make them blank.
>
> Like I said and like some others have echoed, removing the local
> administrative creds is not feasible in reality. Maybe in Microsoft,
> but not in any of their customers I've seen. the larger the
> environment, the more likely this would be a method of access for
> support in some situations. Not pretty nor perfect, but then I read
> the blog differently too.
>
>
> Al
>
>
> On 6/27/07, Austin Osuide wrote:
>
>>
>>
>> Absolutely Joe.
>>
>> But I think Al was referring to "security by obscurity"
which is definitely
>> not what I mean to put across here.
>>
>> Just did a google to see if I was alone here (even though I think
you said
>> you agreed with the concept) and found this by Jasper Johansson,
formerly of
>> MS STU:
>>
>> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
>> and thought I should share it. Quick and interesting reading it
makes.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Austin
>>
>>
>>
>>
>>
>>
>>
>> From: ActiveDir-owner@mail.activedir.org
>> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
>> joe
>> Sent: 27 June 2007 03:54
>>
>> To: ActiveDir@mail.activedir.org
>> Subject: RE: [ActiveDir] startup script local admin password
reset
>>
>>
>>
>>
>> obfuscating = to make obscure
>>
>>
>>
>> :)
>>
>>
>>
>> Until such a time that machines can be joined to a domain without
the need
>> for administrative credentials on the machine itself, local admin
creds are
>> likely going to be needed at some point for some reason. Period.
There are
>> times, I am not going to enumerate them, that shit happens and
you fall back
>> to local creds. This is experience from doing some form of support
over the
>> last 10 years in many companies with total seats across all numbering
into
>> the millions of seats and indirectly helping people with this
kind of stuff
>> through joeware/newsgroups likely into the tens of millions of
seats (CPAU
>> for instance is extremely popular in the Novell world as well
as the MSFT
>> world). This is simply reality. I will rail against reality on
a fairly
>> regular basis, anyone who has seen me rant against LDAPS or
running ADI DNS
>> on a Domain Controller has seen me do it, but this issue with
local admin
>> accounts is so big and so ever present in every org I have ever
helped with
>> any level of client assistance that it is just not worth the energy
to rail
>> against. It for intents and purposes is one of the true unwinnable
battles.
>> IF and this is a big IF I could join a machine to a domain without
having
>> any local creds on the box at all, like a push button on the GINA
that said
>> add to the domain I specify when I specify it and it cannot fail
then local
>> creds are not a big deal. Until that day, it is.
>>
>>
>>
>>
>>
>>
>> --
>>
>> 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 8:10 PM
>> To: ActiveDir@mail.activedir.org
>> Subject: RE: [ActiveDir] startup script local admin password
reset
>>
>> There is no obscurity here Al.
>>
>> For a standalone machine, you will need the local admin cred for
elevated
>> privileges.
>>
>> For a machine that's joined to the domain, domain managed accounts
have are
>> given these privilages by default. You can further modify which
domain creds
>> have this level of access. (PS, I know you know and I'm not trying
to teach
>> you to suck eggs, just makes the point)
>>
>> The issue becomes relevant when the number of domain joined machines
>> increases to the point where, to prevent dependencies in the security
levels
>> of machines the local admin passwords have to be different. In
this
>> scenario, your reliance on these creds decreases your security
posture.
>> Keeping the passwords different, available and changed at a regular
>> interval, preferably after every audited request for the cred,
is an
>> overhead which with good planning, you can well do without.
>>
>>
>>
>> And, somehow, I have managed to work quite happily with restricted
>> privileges "as far back" as the XP days J my privileges
are elevated only
>> when I need to. Vista just makes this more routine with less configuration
>> from me and I quite like it. Yes, I've had some hang-ups but I've
been able
>> to resolve them most times by talking to the dev guys if I can
find them or
>> waiting till mass effect of demand causes a change (happens you
know!).
>> Giving users local admin effectively gives you no control over
that box any
>> more if the user so wishes. To cause you harm, all they'd need
is access to
>> google.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Austin
>>
>>
>>
>>
>>
>>
>> From: ActiveDir-owner@mail.activedir.org
>> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
>> Mulnick
>> Sent: 27 June 2007 00:47
>> To: ActiveDir@mail.activedir.org
>> Subject: Re: [ActiveDir] startup script local admin password
reset
>>
>>
>>
>> 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.
>>
>> Al
>>
>>
>>
>>
>> On 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 the situation
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 to have 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
could
>> mean 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
saying many
>> 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 the local admin
password for a given
>> machine whenever it is needed. Also from what I understand, that
tends to
>> get used on a fairly 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.
>> ________________________________
>>
>>
>>
>> ________________________________
>>
>>
>> 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.
>>
>> ________________________________
>>
>>
>>
>>
>>
>>
> .+w֧B+v*rz+v*k}
>
> 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.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
>
--
If you are a SBSer... you had better be reading http://blogs.technet.com/sbs
- the SBS Blog.
..and my blog is at www.sbsdiva.com....
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient
is strictly prohibited. | | | |
| austin
Posts:49
| | 06/28/2007 6:17 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
I have taken it upon myself to find out how often in the last
6mo, in the 140k user env I currently work in, a local admin account has been
used to “fix” an issue.
I’ll lt you know the feed-back I get.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: 28 June 2007 04:57
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Yep, I agree with the concept but don't think it is feasible right
now.
Jesper is a good smart guy, but I don't agree with everything he
says. We differ pretty well on Lockout and this idea of just disabling the
admin ID. If you create another admin ID locally on the machine, sure disable
the builtin but there should be a builtin ID until such a time that we have
what I described previously.
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: Wednesday, June 27, 2007 6:05 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Absolutely Joe.
But I think Al was referring to “security by obscurity” which is
definitely not what I mean to put across here.
Just did a google to see if I was alone here (even though I
think you said you agreed with the concept) and found this by Jasper Johansson,
formerly of MS STU:
http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
and thought I should share it. Quick and interesting reading it makes.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: 27 June 2007 03:54
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
obfuscating= to make obscure
:)
Until such a time that machines can be joined to a domain without
the need for administrative credentials on the machine itself, local admin
creds are likely going to be needed at some point for some reason. Period.
There are times, I am not going to enumerate them, thatshit happens and
youfall back to local creds. This is experience from doing some form of
support over the last 10 years inmany companies with total seats across
all numbering into the millions of seats and indirectly helping people with
this kind of stuff through joeware/newsgroups likely into the tens of millions
of seats (CPAU for instance is extremely popular in the Novell world as well as
the MSFT world). This is simply reality. I will rail against reality on a
fairly regular basis, anyone who has seen me rant against LDAPS or
running ADI DNS on a Domain Controller has seen me do it, but this issue with
local admin accounts is so big and so ever present in every org I have ever
helped with any level of client assistance that it is just not worth the energy
to rail against. It for intents and purposes is one of the true unwinnable
battles. IF and this is a big IF I could join a machine to a domain without
having any local creds on the box at all, like a push button on the GINA that
said add to the domain I specify when I specify it and it cannot fail then
local creds are not a big deal. Until that day, it is.
--
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 8:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
There is no obscurity here Al.
For a standalone machine, you will need the local admin cred for
elevated privileges.
For a machine that’s joined to the domain, domain managed
accounts have are given these privilages by default. You can further modify
which domain creds have this level of access. (PS, I know you know and I’m not
trying to teach you to suck eggs, just makes the point)
The issue becomes relevant when the number of domain joined
machines increases to the point where, to prevent dependencies in the security
levels of machines the local admin passwords have to be different. In this
scenario, your reliance on these creds decreases your security posture. Keeping
the passwords different, available and changed at a regular interval,
preferably after every audited request for the cred, is an overhead which with
good planning, you can well do without.
And, somehow, I have managed to work quite happily with
restricted privileges “as far back” as the XP days J my
privileges are elevated only when I need to. Vista just makes this more routine
with less configuration from me and I quite like it. Yes, I’ve had some
hang-ups but I’ve been able to resolve them most times by talking to the dev
guys if I can find them or waiting till mass effect of demand causes a change
(happens you know!). Giving users local admin effectively gives you no control
over that box any more if the user so wishes. To cause you harm, all they’d
need is access to google.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 27 June 2007 00:47
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
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.
Al
On 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.
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. | | | |
| listmail
Posts:824
| | 06/28/2007 8:31 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.q {
mso-style-name: q
}
SPAN.e {
mso-style-name: e
}
SPAN.EmailStyle21 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle22 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle23 {
COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
page: Section1
}
resend
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: joe [mailto:listmail@joeware.net]
Sent: Thursday, June 28, 2007 8:24 AMTo:
'activedir@activedir.org'Subject: RE: [ActiveDir] startup script
local admin password reset
Ah good luck, getting feedback from the people doing the
real work on clients in an environment of that size is difficult to almost
impossible. I was just out on the US west coast at one of the smaller companies
I deal with with only about 55k or so people and the client people at corporate
said things were done one way and when I was out in a plant where the boots
meets the concrete they were using the machines and IDs in a completely
different way. Several local site folks all asked separately came up with the
same answer. Then I spoke to the central people again and they were like, they
absolutely are not doing it that way. I said "What if they are?". The answer was
"That is a security issue?". I said... "Yes, I know". Basically the people in
the field are not the greatest at getting feedback to corporate, they do
whatever they feel they need to do to keep X rolling down the line because we
build/sell/market X, not computers... In another example from last year, I
walked into a place and was told there was no NT4, I did a scan over the IPs of
supported machines, found over 100 NT4 domains and 300+ NT4 servers... None of
it of course was in the datacenter, it was all out in branch/factory locations
and the centralized people literally didn't have any idea it was out there. Over
the years I have learned when walking into companies to listen to what corporate
people tell me and then go figure out what is really being done.
--
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: Thursday, June 28, 2007 6:17 AMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script
local admin password reset
I
have taken it upon myself to find out how often in the last 6mo, in the 140k
user env I currently work in, a local admin account has been used to fix an
issue.
Ill
lt you know the feed-back I get.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of joeSent: 28 June 2007 04:57To:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script
local admin password reset
Yep, I
agree with the concept but don't think it is feasible right now.
Jesper
is a good smart guy, but I don't agree with everything he says. We differ pretty
well on Lockout and this idea of just disabling the admin ID. If you create
another admin ID locally on the machine, sure disable the builtin but there
should be a builtin ID until such a time that we have what I described
previously.
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: Wednesday, June 27, 2007 6:05
AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
startup script local admin password reset
Absolutely
Joe.
But
I think Al was referring to security by obscurity which is definitely not what
I mean to put across here.
Just
did a google to see if I was alone here (even though I think you said you agreed
with the concept) and found this by Jasper Johansson, formerly of MS
STU:
http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
and thought I should share it. Quick and interesting reading it
makes.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of joeSent: 27 June 2007 03:54To:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] startup script
local admin password reset
obfuscating=
to make obscure
:)
Until
such a time that machines can be joined to a domain without the need for
administrative credentials on the machine itself, local admin creds are likely
going to be needed at some point for some reason. Period. There are times, I am
not going to enumerate them, thatshit happens and youfall back to
local creds. This is experience from doing some form of support over the last 10
years inmany companies with total seats across all numbering into the
millions of seats and indirectly helping people with this kind of stuff through
joeware/newsgroups likely into the tens of millions of seats (CPAU for instance
is extremely popular in the Novell world as well as the MSFT world). This is
simply reality. I will rail against reality on a fairly regular basis, anyone
who has seen me rant against LDAPS or running ADI DNS on a Domain
Controller has seen me do it, but this issue with local admin accounts is so big
and so ever present in every org I have ever helped with any level of client
assistance that it is just not worth the energy to rail against. It for intents
and purposes is one of the true unwinnable battles. IF and this is a big IF I
could join a machine to a domain without having any local creds on the box at
all, like a push button on the GINA that said add to the domain I specify when I
specify it and it cannot fail then local creds are not a big deal. Until that
day, it is.
--
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 8:10
PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
startup script local admin password reset
There
is no obscurity here Al.
For
a standalone machine, you will need the local admin cred for elevated
privileges.
For
a machine thats joined to the domain, domain managed accounts have are given
these privilages by default. You can further modify which domain creds have this
level of access. (PS, I know you know and Im not trying to teach you to suck
eggs, just makes the point)
The
issue becomes relevant when the number of domain joined machines increases to
the point where, to prevent dependencies in the security levels of machines the
local admin passwords have to be different. In this scenario, your reliance on
these creds decreases your security posture. Keeping the passwords different,
available and changed at a regular interval, preferably after every audited
request for the cred, is an overhead which with good planning, you can well do
without.
And,
somehow, I have managed to work quite happily with restricted privileges as far
back as the XP days J my
privileges are elevated only when I need to. Vista just makes this more routine
with less configuration from me and I quite like it. Yes, Ive had some hang-ups
but Ive been able to resolve them most times by talking to the dev guys if I
can find them or waiting till mass effect of demand causes a change (happens you
know!). Giving users local admin effectively gives you no control over that box
any more if the user so wishes. To cause you harm, all theyd need is access to
google.
Regards,
Austin
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al MulnickSent: 27 June 2007 00:47To:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script
local admin password reset
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. Al
On 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
MulnickSent: 26 June 2007 22:43
To: ActiveDir@mail.activedir.orgSubject: 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, RichardSent: 26 June 2007 19:36
To: ActiveDir@mail.activedir.orgSubject: 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 joeSent:
Tuesday, June 26, 2007 1:27 PMTo: ActiveDir@mail.activedir.orgSubject: 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 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 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.
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.
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. | | | |
| listmail
Posts:824
| | 06/28/2007 12:03 PM |
| What happens if something happens and for whatever reason the machine just can't communicate with the domain? Just slam the machine with a new load and hope it works without ever even trying to log in and notice that someone dorked some DNS settings or something so it won't logon to the domain or something like that? Or are you just assuming you are going to use one of the password hacking CDs and try to get in that way?
I do agree that the users shouldn't have the local admin password. Personally I like to see users without any admin level access. I ran marketing and treasury users that way back in the '97 time frame o NT4 and it worked famously, the lowest TCO I have seen on workstations ever. They just didn't break, no one who wasn't qualified to work on them could change anything.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Austin Osuide
Sent: Wednesday, June 27, 2007 5:02 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup script local admin password reset
Ok Al,
I submit :-)
The way I see it is we are both right. In a way. For Desktops that are always connected to the LAN and to which I can easily get a body, if I could have my way, I would disable the local admin account.
For laptops and mobile users, this presents a problem but that's what OU's & GPO's are for.
Interesting topic nonetheless and I'm sure it will continue to present nightmares and huge costs to companies who try to get a tight rein on local admin accounts.
Regards,
Austin
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
Sent: 27 June 2007 17:25
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
I read that differently. I normally have strong
disagreements with putting Microsoft and Security in the same sentence
and often that means I strongly disagree with JesperJ and SteveR
In this case he advocates disabling the administrator account over
letting people obscure their access (there's that word again) by using
the local administrator account. I totally and wholeheartedly agree
that users should not be allowed to use the local administrator
account. That's not what it's for. They should not know the password.
It would help if they could go about their daily lives and install
drivers without that kind of access or without the password. It
doesn't work that way in the real world though I tend to partially
agree with JesperJ on this one - don't give your users the local
administrator password.
He goes on to cover that assertion by saying that if you cannot, then
at least make the password's different. He must have been oxygen
starved though, because later he goes back and says that if you don't
make them all unique and long (hard to guess), make them blank.
Like I said and like some others have echoed, removing the local
administrative creds is not feasible in reality. Maybe in Microsoft,
but not in any of their customers I've seen. the larger the
environment, the more likely this would be a method of access for
support in some situations. Not pretty nor perfect, but then I read
the blog differently too.
Al
On 6/27/07, Austin Osuide wrote:
>
>
>
>
> Absolutely Joe.
>
> But I think Al was referring to "security by obscurity" which is definitely
> not what I mean to put across here.
>
> Just did a google to see if I was alone here (even though I think you said
> you agreed with the concept) and found this by Jasper Johansson, formerly of
> MS STU:
>
> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> and thought I should share it. Quick and interesting reading it makes.
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> joe
> Sent: 27 June 2007 03:54
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
>
> obfuscating = to make obscure
>
>
>
> :)
>
>
>
> Until such a time that machines can be joined to a domain without the need
> for administrative credentials on the machine itself, local admin creds are
> likely going to be needed at some point for some reason. Period. There are
> times, I am not going to enumerate them, that shit happens and you fall back
> to local creds. This is experience from doing some form of support over the
> last 10 years in many companies with total seats across all numbering into
> the millions of seats and indirectly helping people with this kind of stuff
> through joeware/newsgroups likely into the tens of millions of seats (CPAU
> for instance is extremely popular in the Novell world as well as the MSFT
> world). This is simply reality. I will rail against reality on a fairly
> regular basis, anyone who has seen me rant against LDAPS or running ADI DNS
> on a Domain Controller has seen me do it, but this issue with local admin
> accounts is so big and so ever present in every org I have ever helped with
> any level of client assistance that it is just not worth the energy to rail
> against. It for intents and purposes is one of the true unwinnable battles.
> IF and this is a big IF I could join a machine to a domain without having
> any local creds on the box at all, like a push button on the GINA that said
> add to the domain I specify when I specify it and it cannot fail then local
> creds are not a big deal. Until that day, it is.
>
>
>
>
>
>
> --
>
> 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 8:10 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> There is no obscurity here Al.
>
> For a standalone machine, you will need the local admin cred for elevated
> privileges.
>
> For a machine that's joined to the domain, domain managed accounts have are
> given these privilages by default. You can further modify which domain creds
> have this level of access. (PS, I know you know and I'm not trying to teach
> you to suck eggs, just makes the point)
>
> The issue becomes relevant when the number of domain joined machines
> increases to the point where, to prevent dependencies in the security levels
> of machines the local admin passwords have to be different. In this
> scenario, your reliance on these creds decreases your security posture.
> Keeping the passwords different, available and changed at a regular
> interval, preferably after every audited request for the cred, is an
> overhead which with good planning, you can well do without.
>
>
>
> And, somehow, I have managed to work quite happily with restricted
> privileges "as far back" as the XP days J my privileges are elevated only
> when I need to. Vista just makes this more routine with less configuration
> from me and I quite like it. Yes, I've had some hang-ups but I've been able
> to resolve them most times by talking to the dev guys if I can find them or
> waiting till mass effect of demand causes a change (happens you know!).
> Giving users local admin effectively gives you no control over that box any
> more if the user so wishes. To cause you harm, all they'd need is access to
> google.
>
>
>
>
>
> Regards,
>
>
>
> Austin
>
>
>
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
> Mulnick
> Sent: 27 June 2007 00:47
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
>
>
> 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.
>
> Al
>
>
>
>
> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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 could
> mean 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 saying many
> 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 the local admin password for a given
> machine whenever it is needed. Also from what I understand, that tends to
> get used on a fairly 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 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.
> ________________________________
>
>
>
> ________________________________
>
>
> 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.
>
> ________________________________
>
>
>
>
>
.+w֧B+v*rz+v*k}
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.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| sbradcpa
Posts:496
| | 06/28/2007 12:16 PM |
| A bit USA centric post.. apologies.
Friend works for a large firm that does a lot of contract work for a
certain.... Uncle.... Sam.
She gets a laptop.
She gets handed a wireless card.
She gets handed a printer if they deem her printerworthy.
She gets a build that includes PDF writers.
She thought it was dumb when they deployed USB memory sticks and the
encryption software for the usb had to be enabled/installed only with
administrator rights on the laptop... yeah that caused quite a few help
desk calls.
Does she have admin rights? Nope.
Can she add drivers when she's in a hotel? Nope.
Print to the hotel printer? No way.
Borrow someone's wireless card if she forgot hers? Nope. Sorry... only
that card(s) can connect to their network.
Does she sometimes have to live with her limitations? All the time.
But she deals.
But to say that "the larger the environment the more the need for local
admin rights?"... I'm not sure I buy that.
In big firms they "deploy" an image. If someone needs a new build it's
ghosted/imaged out to the person. If the icons moved and the end user
can't move icons, make a cutesy screensaver? Tough. The end users deal.
I don't buy it that I can feasibly do it and you can't.
Oh yeah.. and that firm I"m talking about... their help desk has to be
USA based... no outsourced help desk either.
joe wrote:
> What happens if something happens and for whatever reason the machine just can't communicate with the domain? Just slam the machine with a new load and hope it works without ever even trying to log in and notice that someone dorked some DNS settings or something so it won't logon to the domain or something like that? Or are you just assuming you are going to use one of the password hacking CDs and try to get in that way?
>
> I do agree that the users shouldn't have the local admin password. Personally I like to see users without any admin level access. I ran marketing and treasury users that way back in the '97 time frame o NT4 and it worked famously, the lowest TCO I have seen on workstations ever. They just didn't break, no one who wasn't qualified to work on them could change anything.
>
>
> --
> O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Austin Osuide
> Sent: Wednesday, June 27, 2007 5:02 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
> Ok Al,
> I submit :-)
> The way I see it is we are both right. In a way. For Desktops that are always connected to the LAN and to which I can easily get a body, if I could have my way, I would disable the local admin account.
> For laptops and mobile users, this presents a problem but that's what OU's & GPO's are for.
> Interesting topic nonetheless and I'm sure it will continue to present nightmares and huge costs to companies who try to get a tight rein on local admin accounts.
>
> Regards,
>
> Austin
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
> Sent: 27 June 2007 17:25
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
> I read that differently. I normally have strong
> disagreements with putting Microsoft and Security in the same sentence
> and often that means I strongly disagree with JesperJ and SteveR
>
>
> In this case he advocates disabling the administrator account over
> letting people obscure their access (there's that word again) by using
> the local administrator account. I totally and wholeheartedly agree
> that users should not be allowed to use the local administrator
> account. That's not what it's for. They should not know the password.
> It would help if they could go about their daily lives and install
> drivers without that kind of access or without the password. It
> doesn't work that way in the real world though I tend to partially
> agree with JesperJ on this one - don't give your users the local
> administrator password.
>
> He goes on to cover that assertion by saying that if you cannot, then
> at least make the password's different. He must have been oxygen
> starved though, because later he goes back and says that if you don't
> make them all unique and long (hard to guess), make them blank.
>
> Like I said and like some others have echoed, removing the local
> administrative creds is not feasible in reality. Maybe in Microsoft,
> but not in any of their customers I've seen. the larger the
> environment, the more likely this would be a method of access for
> support in some situations. Not pretty nor perfect, but then I read
> the blog differently too.
>
>
> Al
>
>
> On 6/27/07, Austin Osuide wrote:
>
>>
>>
>> Absolutely Joe.
>>
>> But I think Al was referring to "security by obscurity" which is definitely
>> not what I mean to put across here.
>>
>> Just did a google to see if I was alone here (even though I think you said
>> you agreed with the concept) and found this by Jasper Johansson, formerly of
>> MS STU:
>>
>> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
>> and thought I should share it. Quick and interesting reading it makes.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Austin
>>
>>
>>
>>
>>
>>
>>
>> From: ActiveDir-owner@mail.activedir.org
>> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
>> joe
>> Sent: 27 June 2007 03:54
>>
>> To: ActiveDir@mail.activedir.org
>> Subject: RE: [ActiveDir] startup script local admin password reset
>>
>>
>>
>>
>> obfuscating = to make obscure
>>
>>
>>
>> :)
>>
>>
>>
>> Until such a time that machines can be joined to a domain without the need
>> for administrative credentials on the machine itself, local admin creds are
>> likely going to be needed at some point for some reason. Period. There are
>> times, I am not going to enumerate them, that shit happens and you fall back
>> to local creds. This is experience from doing some form of support over the
>> last 10 years in many companies with total seats across all numbering into
>> the millions of seats and indirectly helping people with this kind of stuff
>> through joeware/newsgroups likely into the tens of millions of seats (CPAU
>> for instance is extremely popular in the Novell world as well as the MSFT
>> world). This is simply reality. I will rail against reality on a fairly
>> regular basis, anyone who has seen me rant against LDAPS or running ADI DNS
>> on a Domain Controller has seen me do it, but this issue with local admin
>> accounts is so big and so ever present in every org I have ever helped with
>> any level of client assistance that it is just not worth the energy to rail
>> against. It for intents and purposes is one of the true unwinnable battles.
>> IF and this is a big IF I could join a machine to a domain without having
>> any local creds on the box at all, like a push button on the GINA that said
>> add to the domain I specify when I specify it and it cannot fail then local
>> creds are not a big deal. Until that day, it is.
>>
>>
>>
>>
>>
>>
>> --
>>
>> 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 8:10 PM
>> To: ActiveDir@mail.activedir.org
>> Subject: RE: [ActiveDir] startup script local admin password reset
>>
>> There is no obscurity here Al.
>>
>> For a standalone machine, you will need the local admin cred for elevated
>> privileges.
>>
>> For a machine that's joined to the domain, domain managed accounts have are
>> given these privilages by default. You can further modify which domain creds
>> have this level of access. (PS, I know you know and I'm not trying to teach
>> you to suck eggs, just makes the point)
>>
>> The issue becomes relevant when the number of domain joined machines
>> increases to the point where, to prevent dependencies in the security levels
>> of machines the local admin passwords have to be different. In this
>> scenario, your reliance on these creds decreases your security posture.
>> Keeping the passwords different, available and changed at a regular
>> interval, preferably after every audited request for the cred, is an
>> overhead which with good planning, you can well do without.
>>
>>
>>
>> And, somehow, I have managed to work quite happily with restricted
>> privileges "as far back" as the XP days J my privileges are elevated only
>> when I need to. Vista just makes this more routine with less configuration
>> from me and I quite like it. Yes, I've had some hang-ups but I've been able
>> to resolve them most times by talking to the dev guys if I can find them or
>> waiting till mass effect of demand causes a change (happens you know!).
>> Giving users local admin effectively gives you no control over that box any
>> more if the user so wishes. To cause you harm, all they'd need is access to
>> google.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Austin
>>
>>
>>
>>
>>
>>
>> From: ActiveDir-owner@mail.activedir.org
>> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
>> Mulnick
>> Sent: 27 June 2007 00:47
>> To: ActiveDir@mail.activedir.org
>> Subject: Re: [ActiveDir] startup script local admin password reset
>>
>>
>>
>> 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.
>>
>> Al
>>
>>
>>
>>
>> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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 could
>> mean 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 saying many
>> 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 the local admin password for a given
>> machine whenever it is needed. Also from what I understand, that tends to
>> get used on a fairly 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 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.
>> ________________________________
>>
>>
>>
>> ________________________________
>>
>>
>> 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.
>>
>> ________________________________
>>
>>
>>
>>
>>
>>
> .+wÖ§B+v*rz+v*k}
>
> 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.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
>
--
If you are a SBSer... you had better be reading http://blogs.technet.com/sbs - the SBS Blog.
..and my blog is at www.sbsdiva.com....
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| Marty1_0
Posts:0
| | 06/29/2007 8:32 AM |
| Shipping material can indeed be a pain in the ass... Point of view customs. We have lost a server already that way that just never passed customs in a specific country. The cost was a bot high and after negotiations, the server was disappeared. So start over again.
On 6/28/07, Al Mulnick wrote:
Some companies don't use change control in favor of "putting it in andtrying it out."
Some companies have it like that.They'd burn the CTO's at this company in effigy and hang them from thenearest yardarm the first time they went on the road (40% of the orgis mobile) and couldn't print a document or use the usb memory stick
that was company provided didn't work because of access rights.Orcouldn't get on the hotel's wireless network because their card friedand they were unable to borrow one from the front desk. That's
prohibitive and not what IT is about in my opinion.Users don't just deal in a company.They get somebody who can do thejob.They expect to have their expectations set and met on a regularbasis.
Will they put up with some oddities? Yes.Not being able to work? Nope.Oh, nice to see that the company you describe is able to provideprinters for their workers that meet all the workers needs, including
those that travel more than 60% of the time.That's pretty coolalthough not the norm from the companies I've seen.Small company mistake with permissions - 1 day of outage while you goaround and fix it and propagate the fix.
Extra Large company mistake with permissions - 3 weeks outage whileyou diagnose, fix and prevent from happening again while fixpropagates.There's a difference Susan.It can be large.In a multinational company where you're constantly
hiring/firing/expanding/contracting/outsourcing/insourcing you cannotaccount for every change.You cannot make them purchase the samehardware everywhere because in some countries you can't get thathardware.Ship it you say?Go for it says I.Let me know how that
customs agent likes his son's newprinters and hardware. Size makes no difference on that scenario.There could be 20 people in the company in 20 countries and you'd have
that issue.If you're not a gummint agency, then you don't have unlimitedresources.You have to make a choice between users with local adminrights or spending 500.00 (USD) per user to provide uniform equipment
- and it has to meet every need they can dream up because you cannotpossibly manage all the exceptions manually.In your scenario below - their network card is the only one thattouches their network.Ok. I get that.Works for me.But when that
user travels, that card had better work elsewhere.To not deploy aworkable solution invites users and local staff to use workarounds.Those suck even more and cause even more work as you try to preventthat and then lose arguments with senior leaders that insist that it
is far more important to make money for the company than to preventthat user from working because you don't have a good enough solutionfor them to work.It's not a tough issue to understand, but as you can see there are a
lot of different approaches.In fact, most companies have their ownunique blend of solutions to work with these issues. Some are moreacceptable to me than others, but I think that they all have theirreasons and all seem to understand why the issues exist.
Until there's a good way to ensure that those remote users can operatewithout IT support, I have no better way to give them other thanadministrative access in this particular environment.In a security
sensitive environment, where security takes precedence over work andincome (read that as the risk of compromise outweighs the lostproductivity) I can see doing what your friend lives with.When therisk/reward goes the other way, then so does the solution.
On 6/28/07, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:> A bit USA centric post.. apologies.>> Friend works for a large firm that does a lot of contract work for a
> certain.... Uncle.... Sam.> She gets a laptop.> She gets handed a wireless card.> She gets handed a printer if they deem her printerworthy.> She gets a build that includes PDF writers.
> She thought it was dumb when they deployed USB memory sticks and the> encryption software for the usb had to be enabled/installed only with> administrator rights on the laptop... yeah that caused quite a few help
> desk calls.>> Does she have admin rights?Nope.> Can she add drivers when she's in a hotel? Nope.> Print to the hotel printer?No way.> Borrow someone's wireless card if she forgot hers?Nope.Sorry... only
> that card(s) can connect to their network.> Does she sometimes have to live with her limitations?All the time.> But she deals.>>> But to say that "the larger the environment the more the need for local
> admin rights?"... I'm not sure I buy that.>> In big firms they "deploy" an image.If someone needs a new build it's> ghosted/imaged out to the person.If the icons moved and the end user
> can't move icons, make a cutesy screensaver?Tough.The end users deal.>> I don't buy it that I can feasibly do it and you can't.>> Oh yeah.. and that firm I"m talking about... their help desk has to be
> USA based... no outsourced help desk either.>> joe wrote:> > What happens if something happens and for whatever reason the machine just can't communicate with the domain? Just slam the machine with a new load and hope it works without ever even trying to log in and notice that someone dorked some DNS settings or something so it won't logon to the domain or something like that? Or are you just assuming you are going to use one of the password hacking CDs and try to get in that way?
> >> > I do agree that the users shouldn't have the local admin password. Personally I like to see users without any admin level access. I ran marketing and treasury users that way back in the '97 time frame o NT4 and it worked famously, the lowest TCO I have seen on workstations ever. They just didn't break, no one who wasn't qualified to work on them could change anything.
> >> >> > --> > O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm> >> >> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Austin Osuide
> > Sent: Wednesday, June 27, 2007 5:02 PM> > To: ActiveDir@mail.activedir.org> > Subject: RE: [ActiveDir] startup script local admin password reset
> >> > Ok Al,> > I submit :-)> > The way I see it is we are both right. In a way. For Desktops that are always connected to the LAN and to which I can easily get a body, if I could have my way, I would disable the local admin account.
> > For laptops and mobile users, this presents a problem but that's what OU's & GPO's are for.> > Interesting topic nonetheless and I'm sure it will continue to present nightmares and huge costs to companies who try to get a tight rein on local admin accounts.
> >> > Regards,> >> > Austin> >> >> > -----Original Message-----> > From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick> > Sent: 27 June 2007 17:25> > To:
ActiveDir@mail.activedir.org> > Subject: Re: [ActiveDir] startup script local admin password reset> >> > I read that differently. I normally have strong> > disagreements with putting Microsoft and Security in the same sentence
> > and often that means I strongly disagree with JesperJ and SteveR> >> >> > In this case he advocates disabling the administrator account over> > letting people obscure their access (there's that word again) by using
> > the local administrator account.I totally and wholeheartedly agree> > that users should not be allowed to use the local administrator> > account.That's not what it's for. They should not know the password.
> >It would help if they could go about their daily lives and install> > drivers without that kind of access or without the password.It> > doesn't work that way in the real world though I tend to partially
> > agree with JesperJ on this one - don't give your users the local> > administrator password.> >> > He goes on to cover that assertion by saying that if you cannot, then> > at least make the password's different.He must have been oxygen
> > starved though, because later he goes back and says that if you don't> > make them all unique and long (hard to guess), make them blank.> >> > Like I said and like some others have echoed, removing the local
> > administrative creds is not feasible in reality.Maybe in Microsoft,> > but not in any of their customers I've seen.the larger the> > environment, the more likely this would be a method of access for
> > support in some situations. Not pretty nor perfect, but then I read> > the blog differently too.> >> >> > Al> >> >> > On 6/27/07, Austin Osuide <
austin@osuide.com> wrote:> >> >>> >>> >> Absolutely Joe.> >>> >> But I think Al was referring to "security by obscurity" which is definitely
> >> not what I mean to put across here.> >>> >> Just did a google to see if I was alone here (even though I think you said> >> you agreed with the concept) and found this by Jasper Johansson, formerly of
> >> MS STU:> >>> >> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> >> and thought I should share it. Quick and interesting reading it makes.> >>> >>> >>> >> Regards,> >>> >>> >>> >> Austin
> >>> >>> >>> >>> >>> >>> >>> >> From: ActiveDir-owner@mail.activedir.org
> >> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of> >> joe> >>Sent: 27 June 2007 03:54> >>> >>To:
ActiveDir@mail.activedir.org> >>Subject: RE: [ActiveDir] startup script local admin password reset> >>> >>> >>> >>
> >> obfuscating = to make obscure> >>> >>> >>> >> :)> >>> >>> >>> >> Until such a time that machines can be joined to a domain without the need
> >> for administrative credentials on the machine itself, local admin creds are> >> likely going to be needed at some point for some reason. Period. There are> >> times, I am not going to enumerate them, that shit happens and you fall back
> >> to local creds. This is experience from doing some form of support over the> >> last 10 years in many companies with total seats across all numbering into> >> the millions of seats and indirectly helping people with this kind of stuff
> >> through joeware/newsgroups likely into the tens of millions of seats (CPAU> >> for instance is extremely popular in the Novell world as well as the MSFT> >> world). This is simply reality. I will rail against reality on a fairly
> >> regular basis, anyone who has seen me rant against LDAPSor running ADI DNS> >> on a Domain Controller has seen me do it, but this issue with local admin> >> accounts is so big and so ever present in every org I have ever helped with
> >> any level of client assistance that it is just not worth the energy to rail> >> against. It for intents and purposes is one of the true unwinnable battles.> >> IF and this is a big IF I could join a machine to a domain without having
> >> any local creds on the box at all, like a push button on the GINA that said> >> add to the domain I specify when I specify it and it cannot fail then local> >> creds are not a big deal. Until that day, it is.
> >>> >>> >>> >>> >>> >>> >> --> >>> >> 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 8:10 PM> >>To: ActiveDir@mail.activedir.org> >>Subject: RE: [ActiveDir] startup script local admin password reset
> >>> >> There is no obscurity here Al.> >>> >> For a standalone machine, you will need the local admin cred for elevated> >> privileges.> >>
> >> For a machine that's joined to the domain, domain managed accounts have are> >> given these privilages by default. You can further modify which domain creds> >> have this level of access. (PS, I know you know and I'm not trying to teach
> >> you to suck eggs, just makes the point)> >>> >> The issue becomes relevant when the number of domain joined machines> >> increases to the point where, to prevent dependencies in the security levels
> >> of machines the local admin passwords have to be different. In this> >> scenario, your reliance on these creds decreases your security posture.> >> Keeping the passwords different, available and changed at a regular
> >> interval, preferably after every audited request for the cred, is an> >> overhead which with good planning, you can well do without.> >>> >>> >>> >> And, somehow, I have managed to work quite happily with restricted
> >> privileges "as far back" as the XP days J my privileges are elevated only> >> when I need to. Vista just makes this more routine with less configuration> >> from me and I quite like it. Yes, I've had some hang-ups but I've been able
> >> to resolve them most times by talking to the dev guys if I can find them or> >> waiting till mass effect of demand causes a change (happens you know!).> >> Giving users local admin effectively gives you no control over that box any
> >> more if the user so wishes. To cause you harm, all they'd need is access to> >> google.> >>> >>> >>> >>> >>> >> Regards,
> >>> >>> >>> >> Austin> >>> >>> >>> >>> >>> >>> >> From:
ActiveDir-owner@mail.activedir.org> >> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al> >> Mulnick> >>Sent: 27 June 2007 00:47
> >>To: ActiveDir@mail.activedir.org> >>Subject: Re: [ActiveDir] startup script local admin password reset> >>> >>
> >>> >> 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.> >>> >>Al> >>> >>> >>> >>> >> On 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 the situation 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 to have 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 could> >> mean 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 saying many
> >> 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 the local admin password for a given
> >> machine whenever it is needed. Also from what I understand, that tends to> >> get used on a fairly 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 <
amulnick@gmail.com> 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 <
Richard.Kline@rkline.net > 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.> >>________________________________> >>> >>> >>
> >>________________________________> >>> >>> >> 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.> >>> >>________________________________> >>> >>
> >>> >>> >>> >>> > .+wÖ§ B+v*r z+v* k}> >> > 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.> >> > List info : http://www.activedir.org/List.aspx> > List FAQ:
http://www.activedir.org/ListFAQ.aspx> > List archive: http://www.activedir.org/ma/default.aspx> >
> > List info : http://www.activedir.org/List.aspx> > List FAQ: http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx> >> >>> --> If you are a SBSer... you had better be reading
http://blogs.technet.com/sbs - the SBS Blog.>> ..and my blog is at www.sbsdiva.com....>> List info : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx> List archive: http://www.activedir.org/ma/default.aspx
> | | | |
| listmail
Posts:824
| | 06/29/2007 10:29 AM |
| :)
I recall South America, Africa, and most of the AsiaPac
outside of Japan/Australia/NZ as being quite challenging. Shipments for
deployments in those areas needed to be led by months and even then more often
than not dates were missed as something is sitting on a doc or some revolution
is going on or something like that.
The things I see as the only way to solve this securely
are
1. Absolutely bone dead generic drivers that exist on every
machine by default for some items like Network and Printers. May not be the
best, but enough to get the job done if you are off the network or need to print
something. The idea I have seen in some companies to try and have every
conceivable driver in place just isn't feasible and the scaling sucks. This a
problem for Microsoft to solve with the vendors. MSFT writes the standard
driver, everyone says yeah or nay to using it and publishes it on their
packaging. People that need the generic capabilities (like hotels, etc) then buy
the ones that are written to use the generic standards, everyone else that can
tune their systems to be hot rods andcan buy the tuned custom
ones.
2. A change to Windows so someone doesn't need local admin
to get joined to a domain. This a bit tricky though right? What happens when you
join a domain? The machine is now controlled by that domain... uh oh where is
the security? That is a quick end around corporate policy etc... Just take it
home and join a home domain and voila, you now do what you want on the machine.
Maybe they should have to have a secret key to make the machine allow them to do
the join... oh yeah, that is called local admin rights... Anyone for
another lap in the pool? I would like to solve this problem but honestly
in the limited time I have put into thinking about it, I am at a loss. Honestly,
if I had to guess, I would guess we will goaway from the domain model and
to a more decentralized model. Consider an enterprise which is a series
ofFederations (I am not saying this current technology, I am talking
concept) with heavy peer to peer capability.10's, 100's, 1000's of
thousands of trust agreements all automatically managed with business rules and
access permissions and acceptable use policies and exceptions all bound to the
resources that people want to access.
3.A change to Windows to get network up
and running without being able to install
anything but being able to muck with the settings if necessary to say enter an
IP, etc. Maybe it tries for DHCP but if it fails, it pops a box and says, "Hey
you want me to pick a random useless 169 address or do you want to actually
enter something useful? I have noticed the traffic on the network now seems to
be going to addresses like so... and x.x.x.x appears to be a router of some sort
and most of the machines initiating requests on the local network (as evidenced
by arp requests) all seem to have IPs like so...". Yes this can be done. Do a
network trace some time and look at how much info is
there.
--
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 Bart Van den
WyngaertSent: Friday, June 29, 2007 8:33 AMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] startup script
local admin password reset
Shipping material can indeed be a pain in the ass... Point of view customs.
We have lost a server already that way that just never passed customs in a
specific country. The cost was a bot high and after negotiations, the server was
disappeared. So start over again.
On 6/28/07, Al
Mulnick
wrote:
Some
companies don't use change control in favor of "putting it in andtrying it
out."Some companies have it like that.They'd burn the CTO's at this
company in effigy and hang them from thenearest yardarm the first time
they went on the road (40% of the orgis mobile) and couldn't print a
document or use the usb memory stick that was company provided didn't work
because of access rights.Orcouldn't get on the hotel's
wireless network because their card friedand they were unable to borrow
one from the front desk. That's prohibitive and not what IT is about in my
opinion.Users don't just deal in a company.They get
somebody who can do thejob.They expect to have their
expectations set and met on a regularbasis.Will they put up with
some oddities? Yes.Not being able to work? Nope.Oh, nice
to see that the company you describe is able to provideprinters for their
workers that meet all the workers needs, including those that travel more
than 60% of the time.That's pretty coolalthough not the norm
from the companies I've seen.Small company mistake with permissions -
1 day of outage while you goaround and fix it and propagate the fix.
Extra Large company mistake with permissions - 3 weeks outage whileyou
diagnose, fix and prevent from happening again while
fixpropagates.There's a difference Susan.It can be
large.In a multinational company where you're constantly
hiring/firing/expanding/contracting/outsourcing/insourcing you
cannotaccount for every change.You cannot make them purchase
the samehardware everywhere because in some countries you can't get
thathardware.Ship it you say?Go for it says
I.Let me know how that
customs agent likes his son's newprinters and hardware. Size makes no
difference on that scenario.There could be 20 people in the company in 20
countries and you'd have that issue.If you're not a gummint
agency, then you don't have unlimitedresources.You have to
make a choice between users with local adminrights or spending 500.00
(USD) per user to provide uniform equipment - and it has to meet every
need they can dream up because you cannotpossibly manage all the
exceptions manually.In your scenario below - their network card is the
only one thattouches their network.Ok. I get
that.Works for me.But when that user travels, that
card had better work elsewhere.To not deploy aworkable
solution invites users and local staff to use workarounds.Those suck even
more and cause even more work as you try to preventthat and then lose
arguments with senior leaders that insist that it is far more important to
make money for the company than to preventthat user from working because
you don't have a good enough solutionfor them to work.It's not a
tough issue to understand, but as you can see there are a lot of different
approaches.In fact, most companies have their ownunique blend
of solutions to work with these issues. Some are moreacceptable to me than
others, but I think that they all have theirreasons and all seem to
understand why the issues exist. Until there's a good way to ensure
that those remote users can operatewithout IT support, I have no better
way to give them other thanadministrative access in this particular
environment.In a security sensitive environment, where
security takes precedence over work andincome (read that as the risk of
compromise outweighs the lostproductivity) I can see doing what your
friend lives with.When therisk/reward goes the other way, then
so does the solution. On 6/28/07, Susan Bradley, CPA aka Ebitz - SBS
Rocks [MVP] wrote:>
A bit USA centric post.. apologies.>> Friend works for a large
firm that does a lot of contract work for a > certain.... Uncle....
Sam.> She gets a laptop.> She gets handed a wireless
card.> She gets handed a printer if they deem her
printerworthy.> She gets a build that includes PDF writers. >
She thought it was dumb when they deployed USB memory sticks and the>
encryption software for the usb had to be enabled/installed only with>
administrator rights on the laptop... yeah that caused quite a few help
> desk calls.>> Does she have admin
rights?Nope.> Can she add drivers when she's in a hotel?
Nope.> Print to the hotel printer?No way.> Borrow
someone's wireless card if she forgot
hers?Nope.Sorry... only > that card(s) can
connect to their network.> Does she sometimes have to live with her
limitations?All the time.> But she
deals.>>> But to say that "the larger the environment the
more the need for local > admin rights?"... I'm not sure I buy
that.>> In big firms they "deploy" an image.If
someone needs a new build it's> ghosted/imaged out to the
person.If the icons moved and the end user > can't move
icons, make a cutesy screensaver?Tough.The end users
deal.>> I don't buy it that I can feasibly do it and you
can't.>> Oh yeah.. and that firm I"m talking about... their help
desk has to be > USA based... no outsourced help desk
either.>> joe wrote:> > What happens if something
happens and for whatever reason the machine just can't communicate with the
domain? Just slam the machine with a new load and hope it works without ever
even trying to log in and notice that someone dorked some DNS settings or
something so it won't logon to the domain or something like that? Or are you
just assuming you are going to use one of the password hacking CDs and try to
get in that way? > >> > I do agree that the users
shouldn't have the local admin password. Personally I like to see users
without any admin level access. I ran marketing and treasury users that way
back in the '97 time frame o NT4 and it worked famously, the lowest TCO I have
seen on workstations ever. They just didn't break, no one who wasn't qualified
to work on them could change anything. > >> >> >
--> > O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm>
>> >> > -----Original Message----- > > From:
ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide > > Sent: Wednesday, June 27, 2007 5:02
PM> > To: ActiveDir@mail.activedir.org>
> Subject: RE: [ActiveDir] startup script local admin password reset
> >> > Ok Al,> > I submit :-)> > The
way I see it is we are both right. In a way. For Desktops that are always
connected to the LAN and to which I can easily get a body, if I could have my
way, I would disable the local admin account. > > For laptops and
mobile users, this presents a problem but that's what OU's & GPO's are
for.> > Interesting topic nonetheless and I'm sure it will continue
to present nightmares and huge costs to companies who try to get a tight rein
on local admin accounts. > >> > Regards,>
>> > Austin> >> >> > -----Original
Message-----> > From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick> > Sent: 27 June 2007 17:25> > To:
ActiveDir@mail.activedir.org>
> Subject: Re: [ActiveDir] startup script local admin password
reset> >> > I read that
differently. I normally have strong> >
disagreements with putting Microsoft and Security in the same sentence
> > and often that means I strongly disagree with JesperJ and
SteveR> >> >> > In this case
he advocates disabling the administrator account over> > letting
people obscure their access (there's that word again) by using > >
the local administrator account.I totally and wholeheartedly
agree> > that users should not be allowed to use the local
administrator> > account.That's not what it's for. They
should not know the password. > >It would help if they
could go about their daily lives and install> > drivers without that
kind of access or without the password.It> > doesn't
work that way in the real world though I tend to partially > > agree
with JesperJ on this one - don't give your users the local> >
administrator password.> >> > He goes on to cover that
assertion by saying that if you cannot, then> > at least make the
password's different.He must have been oxygen > >
starved though, because later he goes back and says that if you don't>
> make them all unique and long (hard to guess), make them blank.>
>> > Like I said and like some others have echoed, removing the
local > > administrative creds is not feasible in
reality.Maybe in Microsoft,> > but not in any of their
customers I've seen.the larger the> > environment, the
more likely this would be a method of access for > > support in some
situations. Not pretty nor perfect, but then I read> > the blog
differently too.> >> >> > Al>
>> >> > On 6/27/07, Austin Osuide < austin@osuide.com> wrote:>
>> >>> >>> >> Absolutely
Joe.> >>> >> But I think Al was referring to
"security by obscurity" which is definitely > >> not what I mean
to put across here.> >>> >> Just did a google to see
if I was alone here (even though I think you said> >> you agreed
with the concept) and found this by Jasper Johansson, formerly of >
>> MS STU:> >>> >> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx>
>> and thought I should share it. Quick and interesting reading it
makes.> >>> >>> >>> >>
Regards,> >>> >>> >>> >>
Austin > >>> >>> >>>
>>> >>> >>> >>> >>
From: ActiveDir-owner@mail.activedir.org
> >> [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of> >> joe> >>Sent: 27 June
2007 03:54> >>> >>To: ActiveDir@mail.activedir.org>
>>Subject: RE: [ActiveDir] startup script local admin
password reset> >>> >>> >>>
>> > >> obfuscating = to make obscure>
>>> >>> >>> >> :)>
>>> >>> >>> >> Until such a time
that machines can be joined to a domain without the need > >> for
administrative credentials on the machine itself, local admin creds
are> >> likely going to be needed at some point for some reason.
Period. There are> >> times, I am not going to enumerate them,
that shit happens and you fall back > >> to local creds. This is
experience from doing some form of support over the> >> last 10
years in many companies with total seats across all numbering into>
>> the millions of seats and indirectly helping people with this kind of
stuff > >> through joeware/newsgroups likely into the tens of
millions of seats (CPAU> >> for instance is extremely popular in
the Novell world as well as the MSFT> >> world). This is simply
reality. I will rail against reality on a fairly > >> regular
basis, anyone who has seen me rant against LDAPSor running ADI
DNS> >> on a Domain Controller has seen me do it, but this issue
with local admin> >> accounts is so big and so ever present in
every org I have ever helped with > >> any level of client
assistance that it is just not worth the energy to rail> >>
against. It for intents and purposes is one of the true unwinnable
battles.> >> IF and this is a big IF I could join a machine to a
domain without having > >> any local creds on the box at all,
like a push button on the GINA that said> >> add to the domain I
specify when I specify it and it cannot fail then local> >> creds
are not a big deal. Until that day, it is. > >>>
>>> >>> >>> >>>
>>> >> --> >>> >> 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 8:10 PM>
>>To: ActiveDir@mail.activedir.org>
>>Subject: RE: [ActiveDir] startup script local admin
password reset > >>> >> There is no obscurity here
Al.> >>> >> For a standalone machine, you will need
the local admin cred for elevated> >> privileges.>
>>> >> For a machine that's joined to the domain, domain
managed accounts have are> >> given these privilages by default.
You can further modify which domain creds> >> have this level of
access. (PS, I know you know and I'm not trying to teach > >> you
to suck eggs, just makes the point)> >>> >> The
issue becomes relevant when the number of domain joined machines>
>> increases to the point where, to prevent dependencies in the security
levels > >> of machines the local admin passwords have to be
different. In this> >> scenario, your reliance on these creds
decreases your security posture.> >> Keeping the passwords
different, available and changed at a regular > >> interval,
preferably after every audited request for the cred, is an> >>
overhead which with good planning, you can well do without.>
>>> >>> >>> >> And, somehow, I
have managed to work quite happily with restricted > >>
privileges "as far back" as the XP days J my privileges are elevated
only> >> when I need to. Vista just makes this more routine with
less configuration> >> from me and I quite like it. Yes, I've had
some hang-ups but I've been able > >> to resolve them most times
by talking to the dev guys if I can find them or> >> waiting till
mass effect of demand causes a change (happens you know!).> >>
Giving users local admin effectively gives you no control over that box any
> >> more if the user so wishes. To cause you harm, all they'd
need is access to> >> google.> >>>
>>> >>> >>> >>> >>
Regards, > >>> >>> >>> >>
Austin> >>> >>> >>>
>>> >>> >>> >> From: ActiveDir-owner@mail.activedir.org>
>> [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al> >> Mulnick> >>Sent: 27
June 2007 00:47 > >>To: ActiveDir@mail.activedir.org>
>>Subject: Re: [ActiveDir] startup script local admin
password reset> >>> >>> >>>
>> 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.> >>>
>>Al> >>> >>>
>>> >>> >> On 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 the situation 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 to have 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 could> >> mean
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 saying many > >> 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 the local admin password for a given >
>> machine whenever it is needed. Also from what I understand, that
tends to> >> get used on a fairly 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 < amulnick@gmail.com>
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 <
Richard.Kline@rkline.net > 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.>
>>________________________________> >>>
>>> >> >
>>________________________________> >>>
>>> >> 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.> >>>
>>________________________________> >>>
>> > >>> >>> >>>
>>> > .+wÖ§ B+v*r
z+v* k}> >> > 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.> >> > List
info : http://www.activedir.org/List.aspx>
> List FAQ: http://www.activedir.org/ListFAQ.aspx>
> List archive: http://www.activedir.org/ma/default.aspx>
> > > List info : http://www.activedir.org/List.aspx>
> List FAQ: http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx>
>> >>> --> If you are a SBSer... you had
better be reading http://blogs.technet.com/sbs - the SBS
Blog.>> ..and my blog is at www.sbsdiva.com....>>
List info : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx>
List archive: http://www.activedir.org/ma/default.aspx
> | | | |
| MThommes
Posts:106
| | 06/29/2007 10:39 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }
I don’t think I’ve
seen this mentioned in this thread. How do you address the issue of “physical
possession is all you need to be a local admin”? A quick boot with a floppy
that has a program to change the local SAM database is all it takes. Maybe
Bitlocker that comes with Vista/Server 2008 takes care of this issue?
Mike Thommes
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, June 29, 2007 9:29
AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] startup
script local admin password reset
:)
I recall South America, Africa,
and most of the AsiaPac outside of Japan/Australia/NZ as being quite
challenging. Shipments for deployments in those areas needed to be led by
months and even then more often than not dates were missed as something is
sitting on a doc or some revolution is going on or something like that.
The things I see as the only way to solve
this securely are
1. Absolutely bone dead generic drivers
that exist on every machine by default for some items like Network and
Printers. May not be the best, but enough to get the job done if you are off
the network or need to print something. The idea I have seen in some companies
to try and have every conceivable driver in place just isn't feasible and the
scaling sucks. This a problem for Microsoft to solve with the vendors. MSFT
writes the standard driver, everyone says yeah or nay to using it and publishes
it on their packaging. People that need the generic capabilities (like hotels,
etc) then buy the ones that are written to use the generic standards, everyone
else that can tune their systems to be hot rods andcan buy the tuned
custom ones.
2. A change to Windows so someone doesn't
need local admin to get joined to a domain. This a bit tricky though right? What
happens when you join a domain? The machine is now controlled by that domain...
uh oh where is the security? That is a quick end around corporate policy etc...
Just take it home and join a home domain and voila, you now do what you want on
the machine. Maybe they should have to have a secret key to make the machine
allow them to do the join... oh yeah, that is called local admin
rights... Anyone for another lap in the pool? I would like to solve
this problem but honestly in the limited time I have put into thinking about
it, I am at a loss. Honestly, if I had to guess, I would guess we will
goaway from the domain model and to a more decentralized model. Consider
an enterprise which is a series ofFederations (I am not saying this
current technology, I am talking concept) with heavy peer to peer
capability.10's, 100's, 1000's of thousands of trust agreements all
automatically managed with business rules and access permissions and acceptable
use policies and exceptions all bound to the resources that people want to
access.
3.A change to Windows to get network
up and running without being able to install anything but being able to muck
with the settings if necessary to say enter an IP, etc. Maybe it tries for DHCP
but if it fails, it pops a box and says, "Hey you want me to pick a random
useless 169 address or do you want to actually enter something useful? I have
noticed the traffic on the network now seems to be going to addresses like
so... and x.x.x.x appears to be a router of some sort and most of the machines
initiating requests on the local network (as evidenced by arp requests) all
seem to have IPs like so...". Yes this can be done. Do a network trace
some time and look at how much info is there.
--
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 Bart Van den Wyngaert
Sent: Friday, June 29, 2007 8:33
AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup
script local admin password reset
Shipping material can indeed be a pain in the ass... Point of view
customs. We have lost a server already that way that just never passed customs
in a specific country. The cost was a bot high and after negotiations, the
server was disappeared. So start over again.
On 6/28/07, Al
Mulnick
wrote:
Some companies don't use change control in favor of "putting it in
and
trying it out."
Some companies have it like that.
They'd burn the CTO's at this company in effigy and hang them from the
nearest yardarm the first time they went on the road (40% of the org
is mobile) and couldn't print a document or use the usb memory stick
that was company provided didn't work because of access rights.Or
couldn't get on the hotel's wireless network because their card fried
and they were unable to borrow one from the front desk. That's
prohibitive and not what IT is about in my opinion.
Users don't just deal in a company.They get somebody who can do the
job.They expect to have their expectations set and met on a regular
basis.
Will they put up with some oddities? Yes.Not being able to work?
Nope.
Oh, nice to see that the company you describe is able to provide
printers for their workers that meet all the workers needs, including
those that travel more than 60% of the time.That's pretty cool
although not the norm from the companies I've seen.
Small company mistake with permissions - 1 day of outage while you go
around and fix it and propagate the fix.
Extra Large company mistake with permissions - 3 weeks outage while
you diagnose, fix and prevent from happening again while fix
propagates.
There's a difference Susan.It can be large.
In a multinational company where you're constantly
hiring/firing/expanding/contracting/outsourcing/insourcing you cannot
account for every change.You cannot make them purchase the same
hardware everywhere because in some countries you can't get that
hardware.Ship it you say?Go for it says
I.Let me know how that
customs agent likes his son's new
printers and hardware. Size makes no difference on that scenario.
There could be 20 people in the company in 20 countries and you'd have
that issue.
If you're not a gummint agency, then you don't have unlimited
resources.You have to make a choice between users with local admin
rights or spending 500.00 (USD) per user to provide uniform equipment
- and it has to meet every need they can dream up because you cannot
possibly manage all the exceptions manually.
In your scenario below - their network card is the only one that
touches their network.Ok. I get that.Works for
me.But when that
user travels, that card had better work elsewhere.To not deploy a
workable solution invites users and local staff to use workarounds.
Those suck even more and cause even more work as you try to prevent
that and then lose arguments with senior leaders that insist that it
is far more important to make money for the company than to prevent
that user from working because you don't have a good enough solution
for them to work.
It's not a tough issue to understand, but as you can see there are a
lot of different approaches.In fact, most companies have their own
unique blend of solutions to work with these issues. Some are more
acceptable to me than others, but I think that they all have their
reasons and all seem to understand why the issues exist.
Until there's a good way to ensure that those remote users can operate
without IT support, I have no better way to give them other than
administrative access in this particular environment.In a security
sensitive environment, where security takes precedence over work and
income (read that as the risk of compromise outweighs the lost
productivity) I can see doing what your friend lives with.When the
risk/reward goes the other way, then so does the solution.
On 6/28/07, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
wrote:
> A bit USA
centric post.. apologies.
>
> Friend works for a large firm that does a lot of contract work for a
> certain.... Uncle.... Sam.
> She gets a laptop.
> She gets handed a wireless card.
> She gets handed a printer if they deem her printerworthy.
> She gets a build that includes PDF writers.
> She thought it was dumb when they deployed USB memory sticks and the
> encryption software for the usb had to be enabled/installed only with
> administrator rights on the laptop... yeah that caused quite a few help
> desk calls.
>
> Does she have admin rights?Nope.
> Can she add drivers when she's in a hotel? Nope.
> Print to the hotel printer?No way.
> Borrow someone's wireless card if she forgot
hers?Nope.Sorry... only
> that card(s) can connect to their network.
> Does she sometimes have to live with her limitations?All the
time.
> But she deals.
>
>
> But to say that "the larger the environment the more the need for
local
> admin rights?"... I'm not sure I buy that.
>
> In big firms they "deploy" an image.If someone needs
a new build it's
> ghosted/imaged out to the person.If the icons moved and the
end user
> can't move icons, make a cutesy
screensaver?Tough.The end users deal.
>
> I don't buy it that I can feasibly do it and you can't.
>
> Oh yeah.. and that firm I"m talking about... their help desk has to
be
> USA
based... no outsourced help desk either.
>
> joe wrote:
> > What happens if something happens and for whatever reason the machine
just can't communicate with the domain? Just slam the machine with a new load
and hope it works without ever even trying to log in and notice that someone
dorked some DNS settings or something so it won't logon to the domain or
something like that? Or are you just assuming you are going to use one of the
password hacking CDs and try to get in that way?
> >
> > I do agree that the users shouldn't have the local admin password.
Personally I like to see users without any admin level access. I ran marketing
and treasury users that way back in the '97 time frame o NT4 and it worked
famously, the lowest TCO I have seen on workstations ever. They just didn't
break, no one who wasn't qualified to work on them could change anything.
> >
> >
> > --
> > O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Austin Osuide
> > Sent: Wednesday, June 27, 2007 5:02 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] startup script local admin password reset
> >
> > Ok Al,
> > I submit :-)
> > The way I see it is we are both right. In a way. For Desktops that
are always connected to the LAN and to which I can easily get a body, if I
could have my way, I would disable the local admin account.
> > For laptops and mobile users, this presents a problem but that's what
OU's & GPO's are for.
> > Interesting topic nonetheless and I'm sure it will continue to
present nightmares and huge costs to companies who try to get a tight rein on
local admin accounts.
> >
> > Regards,
> >
> > Austin
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
> > Sent: 27 June 2007 17:25
> > To: ActiveDir@mail.activedir.org
> > Subject: Re: [ActiveDir] startup script local admin password reset
> >
> > I read that differently. I normally
have strong
> > disagreements with putting Microsoft and Security in the same
sentence
> > and often that means I strongly disagree with JesperJ and SteveR
> >
> >
> > In this case he advocates disabling the administrator account over
> > letting people obscure their access (there's that word again) by
using
> > the local administrator account.I totally and
wholeheartedly agree
> > that users should not be allowed to use the local administrator
> > account.That's not what it's for. They should not know the
password.
> >It would help if they could go about their daily lives and
install
> > drivers without that kind of access or without the
password.It
> > doesn't work that way in the real world though I tend to partially
> > agree with JesperJ on this one - don't give your users the local
> > administrator password.
> >
> > He goes on to cover that assertion by saying that if you cannot, then
> > at least make the password's different.He must have been
oxygen
> > starved though, because later he goes back and says that if you don't
> > make them all unique and long (hard to guess), make them blank.
> >
> > Like I said and like some others have echoed, removing the local
> > administrative creds is not feasible in reality.Maybe in
Microsoft,
> > but not in any of their customers I've seen.the larger
the
> > environment, the more likely this would be a method of access for
> > support in some situations. Not pretty nor perfect, but then I read
> > the blog differently too.
> >
> >
> > Al
> >
> >
> > On 6/27/07, Austin Osuide < austin@osuide.com>
wrote:
> >
> >>
> >>
> >> Absolutely Joe.
> >>
> >> But I think Al was referring to "security by obscurity"
which is definitely
> >> not what I mean to put across here.
> >>
> >> Just did a google to see if I was alone here (even though I think
you said
> >> you agreed with the concept) and found this by Jasper Johansson,
formerly of
> >> MS STU:
> >>
> >> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> >> and thought I should share it. Quick and interesting reading it
makes.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Austin
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: ActiveDir-owner@mail.activedir.org
> >> [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of
> >> joe
> >>Sent: 27 June 2007 03:54
> >>
> >>To: ActiveDir@mail.activedir.org
> >>Subject: RE: [ActiveDir] startup script local admin
password reset
> >>
> >>
> >>
> >>
> >> obfuscating = to make obscure
> >>
> >>
> >>
> >> :)
> >>
> >>
> >>
> >> Until such a time that machines can be joined to a domain without
the need
> >> for administrative credentials on the machine itself, local admin
creds are
> >> likely going to be needed at some point for some reason. Period.
There are
> >> times, I am not going to enumerate them, that shit happens and
you fall back
> >> to local creds. This is experience from doing some form of
support over the
> >> last 10 years in many companies with total seats across all
numbering into
> >> the millions of seats and indirectly helping people with this
kind of stuff
> >> through joeware/newsgroups likely into the tens of millions of
seats (CPAU
> >> for instance is extremely popular in the Novell world as well as
the MSFT
> >> world). This is simply reality. I will rail against reality on a
fairly
> >> regular basis, anyone who has seen me rant against
LDAPSor running ADI DNS
> >> on a Domain Controller has seen me do it, but this issue with
local admin
> >> accounts is so big and so ever present in every org I have ever
helped with
> >> any level of client assistance that it is just not worth the
energy to rail
> >> against. It for intents and purposes is one of the true
unwinnable battles.
> >> IF and this is a big IF I could join a machine to a domain
without having
> >> any local creds on the box at all, like a push button on the GINA
that said
> >> add to the domain I specify when I specify it and it cannot fail
then local
> >> creds are not a big deal. Until that day, it is.
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> 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 8:10 PM
> >>To: ActiveDir@mail.activedir.org
> >>Subject: RE: [ActiveDir] startup script local admin
password reset
> >>
> >> There is no obscurity here Al.
> >>
> >> For a standalone machine, you will need the local admin cred for
elevated
> >> privileges.
> >>
> >> For a machine that's joined to the domain, domain managed
accounts have are
> >> given these privilages by default. You can further modify which
domain creds
> >> have this level of access. (PS, I know you know and I'm not
trying to teach
> >> you to suck eggs, just makes the point)
> >>
> >> The issue becomes relevant when the number of domain joined
machines
> >> increases to the point where, to prevent dependencies in the
security levels
> >> of machines the local admin passwords have to be different. In
this
> >> scenario, your reliance on these creds decreases your security
posture.
> >> Keeping the passwords different, available and changed at a
regular
> >> interval, preferably after every audited request for the cred, is
an
> >> overhead which with good planning, you can well do without.
> >>
> >>
> >>
> >> And, somehow, I have managed to work quite happily with
restricted
> >> privileges "as far back" as the XP days J my privileges
are elevated only
> >> when I need to. Vista just makes
this more routine with less configuration
> >> from me and I quite like it. Yes, I've had some hang-ups but I've
been able
> >> to resolve them most times by talking to the dev guys if I can
find them or
> >> waiting till mass effect of demand causes a change (happens you
know!).
> >> Giving users local admin effectively gives you no control over
that box any
> >> more if the user so wishes. To cause you harm, all they'd need is
access to
> >> google.
> >>
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Austin
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: ActiveDir-owner@mail.activedir.org
> >> [mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al
> >> Mulnick
> >>Sent: 27 June 2007 00:47
> >>To: ActiveDir@mail.activedir.org
> >>Subject: Re: [ActiveDir] startup script local admin
password reset
> >>
> >>
> >>
> >> 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.
> >>
> >>Al
> >>
> >>
> >>
> >>
> >> On 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 the situation
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 to have 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 could
> >> mean 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
saying many
> >> 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 the local admin
password for a given
> >> machine whenever it is needed. Also from what I understand, that
tends to
> >> get used on a fairly 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 < amulnick@gmail.com>
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 < Richard.Kline@rkline.net >
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.
> >>________________________________
> >>
> >>
> >>
> >>________________________________
> >>
> >>
> >> 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.
> >>
> >>________________________________
> >>
> >>
> >>
> >>
> >>
> >>
> > .+wÖ§ B+v*r z+v* k}
> >
> > 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.
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ: http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ: http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
> >
> >
>
> --
> If you are a SBSer... you had better be reading http://blogs.technet.com/sbs - the SBS
Blog.
>
> ..and my blog is at www.sbsdiva.com....
>
> List info : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> | | | |
| amulnick
Posts:163
| | 06/29/2007 10:53 AM |
| bit locker is one way to do it. Basically, the current solution realm
includes encrypting the entire hard drive so that you cannot attach it
to another machine and you cannot boot past the encryption program
access without knowing some piece of information. A password for
example.
Otherwise, if you have physical access, the data is yours. That goes
for any OS pretty much. After all, who's going to write an OS that
they cannot get into should the wetware mess up and go missing or
forget a password? Besides the gov't spooks of course?
On 6/29/07, Thommes, Michael M. wrote:
>
>
>
>
> I don't think I've seen this mentioned in this thread. How do you address
> the issue of "physical possession is all you need to be a local admin"? A
> quick boot with a floppy that has a program to change the local SAM database
> is all it takes. Maybe Bitlocker that comes with Vista/Server 2008 takes
> care of this issue?
>
>
>
> Mike Thommes
>
>
>
> ________________________________
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> joe
> Sent: Friday, June 29, 2007 9:29 AM
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] startup script local admin password reset
>
>
>
>
> :)
>
>
>
> I recall South America, Africa, and most of the AsiaPac outside of
> Japan/Australia/NZ as being quite challenging. Shipments for deployments in
> those areas needed to be led by months and even then more often than not
> dates were missed as something is sitting on a doc or some revolution is
> going on or something like that.
>
>
>
> The things I see as the only way to solve this securely are
>
>
>
> 1. Absolutely bone dead generic drivers that exist on every machine by
> default for some items like Network and Printers. May not be the best, but
> enough to get the job done if you are off the network or need to print
> something. The idea I have seen in some companies to try and have every
> conceivable driver in place just isn't feasible and the scaling sucks. This
> a problem for Microsoft to solve with the vendors. MSFT writes the standard
> driver, everyone says yeah or nay to using it and publishes it on their
> packaging. People that need the generic capabilities (like hotels, etc) then
> buy the ones that are written to use the generic standards, everyone else
> that can tune their systems to be hot rods and can buy the tuned custom
> ones.
>
>
>
> 2. A change to Windows so someone doesn't need local admin to get joined to
> a domain. This a bit tricky though right? What happens when you join a
> domain? The machine is now controlled by that domain... uh oh where is the
> security? That is a quick end around corporate policy etc... Just take it
> home and join a home domain and voila, you now do what you want on the
> machine. Maybe they should have to have a secret key to make the machine
> allow them to do the join... oh yeah, that is called local admin rights...
> Anyone for another lap in the pool? I would like to solve this problem but
> honestly in the limited time I have put into thinking about it, I am at a
> loss. Honestly, if I had to guess, I would guess we will go away from the
> domain model and to a more decentralized model. Consider an enterprise which
> is a series of Federations (I am not saying this current technology, I am
> talking concept) with heavy peer to peer capability. 10's, 100's, 1000's of
> thousands of trust agreements all automatically managed with business rules
> and access permissions and acceptable use policies and exceptions all bound
> to the resources that people want to access.
>
>
>
> 3. A change to Windows to get network up and running without being able to
> install anything but being able to muck with the settings if necessary to
> say enter an IP, etc. Maybe it tries for DHCP but if it fails, it pops a box
> and says, "Hey you want me to pick a random useless 169 address or do you
> want to actually enter something useful? I have noticed the traffic on the
> network now seems to be going to addresses like so... and x.x.x.x appears to
> be a router of some sort and most of the machines initiating requests on the
> local network (as evidenced by arp requests) all seem to have IPs like
> so...". Yes this can be done. Do a network trace some time and look at how
> much info is there.
>
>
>
>
>
>
>
>
>
>
> --
>
> 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
> Bart Van den Wyngaert
> Sent: Friday, June 29, 2007 8:33 AM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] startup script local admin password reset
>
>
> Shipping material can indeed be a pain in the ass... Point of view customs.
> We have lost a server already that way that just never passed customs in a
> specific country. The cost was a bot high and after negotiations, the server
> was disappeared. So start over again.
>
>
>
>
>
>
>
>
>
>
> On 6/28/07, Al Mulnick wrote:
>
> Some companies don't use change control in favor of "putting it in and
> trying it out."
> Some companies have it like that.
> They'd burn the CTO's at this company in effigy and hang them from the
> nearest yardarm the first time they went on the road (40% of the org
> is mobile) and couldn't print a document or use the usb memory stick
> that was company provided didn't work because of access rights. Or
> couldn't get on the hotel's wireless network because their card fried
> and they were unable to borrow one from the front desk. That's
> prohibitive and not what IT is about in my opinion.
>
> Users don't just deal in a company. They get somebody who can do the
> job. They expect to have their expectations set and met on a regular
> basis.
>
> Will they put up with some oddities? Yes. Not being able to work? Nope.
>
> Oh, nice to see that the company you describe is able to provide
> printers for their workers that meet all the workers needs, including
> those that travel more than 60% of the time. That's pretty cool
> although not the norm from the companies I've seen.
>
> Small company mistake with permissions - 1 day of outage while you go
> around and fix it and propagate the fix.
> Extra Large company mistake with permissions - 3 weeks outage while
> you diagnose, fix and prevent from happening again while fix
> propagates.
>
> There's a difference Susan. It can be large.
>
> In a multinational company where you're constantly
> hiring/firing/expanding/contracting/outsourcing/insourcing
> you cannot
> account for every change. You cannot make them purchase the same
> hardware everywhere because in some countries you can't get that
> hardware. Ship it you say? Go for it says I. Let me know how that
> customs agent likes his son's new
> printers and hardware. Size makes no difference on that scenario.
> There could be 20 people in the company in 20 countries and you'd have
> that issue.
>
> If you're not a gummint agency, then you don't have unlimited
> resources. You have to make a choice between users with local admin
> rights or spending 500.00 (USD) per user to provide uniform equipment
> - and it has to meet every need they can dream up because you cannot
> possibly manage all the exceptions manually.
>
> In your scenario below - their network card is the only one that
> touches their network. Ok. I get that. Works for me. But when that
> user travels, that card had better work elsewhere. To not deploy a
> workable solution invites users and local staff to use workarounds.
> Those suck even more and cause even more work as you try to prevent
> that and then lose arguments with senior leaders that insist that it
> is far more important to make money for the company than to prevent
> that user from working because you don't have a good enough solution
> for them to work.
>
> It's not a tough issue to understand, but as you can see there are a
> lot of different approaches. In fact, most companies have their own
> unique blend of solutions to work with these issues. Some are more
> acceptable to me than others, but I think that they all have their
> reasons and all seem to understand why the issues exist.
>
> Until there's a good way to ensure that those remote users can operate
> without IT support, I have no better way to give them other than
> administrative access in this particular environment. In a security
> sensitive environment, where security takes precedence over work and
> income (read that as the risk of compromise outweighs the lost
> productivity) I can see doing what your friend lives with. When the
> risk/reward goes the other way, then so does the solution.
>
> On 6/28/07, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
> wrote:
> > A bit USA centric post.. apologies.
> >
> > Friend works for a large firm that does a lot of contract work for a
> > certain.... Uncle.... Sam.
> > She gets a laptop.
> > She gets handed a wireless card.
> > She gets handed a printer if they deem her printerworthy.
> > She gets a build that includes PDF writers.
> > She thought it was dumb when they deployed USB memory sticks and the
> > encryption software for the usb had to be enabled/installed only with
> > administrator rights on the laptop... yeah that caused quite a few help
> > desk calls.
> >
> > Does she have admin rights? Nope.
> > Can she add drivers when she's in a hotel? Nope.
> > Print to the hotel printer? No way.
> > Borrow someone's wireless card if she forgot hers? Nope. Sorry... only
> > that card(s) can connect to their network.
> > Does she sometimes have to live with her limitations? All the time.
> > But she deals.
> >
> >
> > But to say that "the larger the environment the more the need for local
> > admin rights?"... I'm not sure I buy that.
> >
> > In big firms they "deploy" an image. If someone needs a new build it's
> > ghosted/imaged out to the person. If the icons moved and the end user
> > can't move icons, make a cutesy screensaver? Tough. The end users deal.
> >
> > I don't buy it that I can feasibly do it and you can't.
> >
> > Oh yeah.. and that firm I"m talking about... their help desk has to be
> > USA based... no outsourced help desk either.
> >
> > joe wrote:
> > > What happens if something happens and for whatever reason the machine
> just can't communicate with the domain? Just slam the machine with a new
> load and hope it works without ever even trying to log in and notice that
> someone dorked some DNS settings or something so it won't logon to the
> domain or something like that? Or are you just assuming you are going to use
> one of the password hacking CDs and try to get in that way?
> > >
> > > I do agree that the users shouldn't have the local admin password.
> Personally I like to see users without any admin level access. I ran
> marketing and treasury users that way back in the '97 time frame o NT4 and
> it worked famously, the lowest TCO I have seen on workstations ever. They
> just didn't break, no one who wasn't qualified to work on them could change
> anything.
> > >
> > >
> > > --
> > > O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
> > >
> > >
> > > -----Original Message-----
> > > From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> Austin Osuide
> > > Sent: Wednesday, June 27, 2007 5:02 PM
> > > To: ActiveDir@mail.activedir.org
> > > Subject: RE: [ActiveDir] startup script local admin password reset
> > >
> > > Ok Al,
> > > I submit :-)
> > > The way I see it is we are both right. In a way. For Desktops that are
> always connected to the LAN and to which I can easily get a body, if I could
> have my way, I would disable the local admin account.
> > > For laptops and mobile users, this presents a problem but that's what
> OU's & GPO's are for.
> > > Interesting topic nonetheless and I'm sure it will continue to present
> nightmares and huge costs to companies who try to get a tight rein on local
> admin accounts.
> > >
> > > Regards,
> > >
> > > Austin
> > >
> > >
> > > -----Original Message-----
> > > From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
> Mulnick
> > > Sent: 27 June 2007 17:25
> > > To: ActiveDir@mail.activedir.org
> > > Subject: Re: [ActiveDir] startup script local admin password reset
> > >
> > > I read that differently. I normally have strong
> > > disagreements with putting Microsoft and Security in the same sentence
> > > and often that means I strongly disagree with JesperJ and SteveR
> > >
> > >
> > > In this case he advocates disabling the administrator account over
> > > letting people obscure their access (there's that word again) by using
> > > the local administrator account. I totally and wholeheartedly agree
> > > that users should not be allowed to use the local administrator
> > > account. That's not what it's for. They should not know the password.
> > > It would help if they could go about their daily lives and install
> > > drivers without that kind of access or without the password. It
> > > doesn't work that way in the real world though I tend to partially
> > > agree with JesperJ on this one - don't give your users the local
> > > administrator password.
> > >
> > > He goes on to cover that assertion by saying that if you cannot, then
> > > at least make the password's different. He must have been oxygen
> > > starved though, because later he goes back and says that if you don't
> > > make them all unique and long (hard to guess), make them blank.
> > >
> > > Like I said and like some others have echoed, removing the local
> > > administrative creds is not feasible in reality. Maybe in Microsoft,
> > > but not in any of their customers I've seen. the larger the
> > > environment, the more likely this would be a method of access for
> > > support in some situations. Not pretty nor perfect, but then I read
> > > the blog differently too.
> > >
> > >
> > > Al
> > >
> > >
> > > On 6/27/07, Austin Osuide wrote:
> > >
> > >>
> > >>
> > >> Absolutely Joe.
> > >>
> > >> But I think Al was referring to "security by obscurity" which is
> definitely
> > >> not what I mean to put across here.
> > >>
> > >> Just did a google to see if I was alone here (even though I think you
> said
> > >> you agreed with the concept) and found this by Jasper Johansson,
> formerly of
> > >> MS STU:
> > >>
> > >>
> http://blogs.technet.com/jesper_johansson/archive/2005/09/19/411303.aspx
> > >> and thought I should share it. Quick and interesting reading it makes.
> > >>
> > >>
> > >>
> > >> Regards,
> > >>
> > >>
> > >>
> > >> Austin
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> From: ActiveDir-owner@mail.activedir.org
> > >> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf
> Of
> > >> joe
> > >> Sent: 27 June 2007 03:54
> > >>
> > >> To: ActiveDir@mail.activedir.org
> > >> Subject: RE: [ActiveDir] startup script local admin password reset
> > >>
> > >>
> > >>
> > >>
> > >> obfuscating = to make obscure
> > >>
> > >>
> > >>
> > >> :)
> > >>
> > >>
> > >>
> > >> Until such a time that machines can be joined to a domain without the
> need
> > >> for administrative credentials on the machine itself, local admin
> creds are
> > >> likely going to be needed at some point for some reason. Period. There
> are
> > >> times, I am not going to enumerate them, that shit happens and you
> fall back
> > >> to local creds. This is experience from doing some form of support
> over the
> > >> last 10 years in many companies with total seats across all numbering
> into
> > >> the millions of seats and indirectly helping people with this kind of
> stuff
> > >> through joeware/newsgroups likely into the tens of millions of seats
> (CPAU
> > >> for instance is extremely popular in the Novell world as well as the
> MSFT
> > >> world). This is simply reality. I will rail against reality on a
> fairly
> > >> regular basis, anyone who has seen me rant against LDAPS or running
> ADI DNS
> > >> on a Domain Controller has seen me do it, but this issue with local
> admin
> > >> accounts is so big and so ever present in every org I have ever helped
> with
> > >> any level of client assistance that it is just not worth the energy to
> rail
> > >> against. It for intents and purposes is one of the true unwinnable
> battles.
> > >> IF and this is a big IF I could join a machine to a domain without
> having
> > >> any local creds on the box at all, like a push button on the GINA that
> said
> > >> add to the domain I specify when I specify it and it cannot fail then
> local
> > >> creds are not a big deal. Until that day, it is.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> 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 8:10 PM
> > >> To: ActiveDir@mail.activedir.org
> > >> Subject: RE: [ActiveDir] startup script local admin password reset
> > >>
> > >> There is no obscurity here Al.
> > >>
> > >> For a standalone machine, you will need the local admin cred for
> elevated
> > >> privileges.
> > >>
> > >> For a machine that's joined to the domain, domain managed accounts
> have are
> > >> given these privilages by default. You can further modify which domain
> creds
> > >> have this level of access. (PS, I know you know and I'm not trying to
> teach
> > >> you to suck eggs, just makes the point)
> > >>
> > >> The issue becomes relevant when the number of domain joined machines
> > >> increases to the point where, to prevent dependencies in the security
> levels
> > >> of machines the local admin passwords have to be different. In this
> > >> scenario, your reliance on these creds decreases your security
> posture.
> > >> Keeping the passwords different, available and changed at a regular
> > >> interval, preferably after every audited request for the cred, is an
> > >> overhead which with good planning, you can well do without.
> > >>
> > >>
> > >>
> > >> And, somehow, I have managed to work quite happily with restricted
> > >> privileges "as far back" as the XP days J my privileges are elevated
> only
> > >> when I need to. Vista just makes this more routine with less
> configuration
> > >> from me and I quite like it. Yes, I've had some hang-ups but I've been
> able
> > >> to resolve them most times by talking to the dev guys if I can find
> them or
> > >> waiting till mass effect of demand causes a change (happens you
> know!).
> > >> Giving users local admin effectively gives you no control over that
> box any
> > >> more if the user so wishes. To cause you harm, all they'd need is
> access to
> > >> google.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Regards,
> > >>
> > >>
> > >>
> > >> Austin
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> From: ActiveDir-owner@mail.activedir.org
> > >> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf
> Of Al
> > >> Mulnick
> > >> Sent: 27 June 2007 00:47
> > >> To: ActiveDir@mail.activedir.org
> > >> Subject: Re: [ActiveDir] startup script local admin password reset
> > >>
> > >>
> > >>
> > >> 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.
> > >>
> > >> Al
> > >>
> > >>
> > >>
> > >>
> > >> On 6/26/07, Austin Osuide 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 the situation 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 to have 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 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
> could
> > >> mean 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 saying
> many
> > >> 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 the local admin password for a
> given
> > >> machine whenever it is needed. Also from what I understand, that tends
> to
> > >> get used on a fairly 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 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.
> > >> ________________________________
> > >>
> > >>
> > >>
> > >> ________________________________
> > >>
> > >>
> > >> 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.
> > >>
> > >> ________________________________
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > > .+wÖ§ B +v* r z +v* k}
> > >
> > > 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.
> > >
> > > List info : http://www.activedir.org/List.aspx
> > > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > > List archive: http://www.activedir.org/ma/default.aspx
> > >
> > > List info : http://www.activedir.org/List.aspx
> > > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > > List archive: http://www.activedir.org/ma/default.aspx
> > >
> > >
> >
> > --
> > If you are a SBSer... you had better be reading
> http://blogs.technet.com/sbs - the SBS Blog.
> >
> > ..and my blog is at www.sbsdiva.com....
> >
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
> >
>
>
.+-� 0�����j�q.+-� 0����ˊ�E��Kj�!i�b��b����ןj�m | | | |
|
|