| Author | Messages | |
amulnick
Posts:138
 | | 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:8
| | 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:8
| | 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:454
| | 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:138
| | 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
> p |
|
|