| Author | Messages | |
listmail
Posts:824
 | | 06/26/2007 11:39 AM |
| For those not on the offline email that Susan is referring to with her "Sucking at lurking" comments there is an email someone sent out that lists the top ten posters by count for the last year and Susan came in second even though when she first joined she said she would be lurking here. Not quite sure how, but I came up with first. I know I write long posts, didn't think I had the largest number of posts though. I go in bursts when I get a chance to catch up. :)
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
Sent: Tuesday, June 26, 2007 9:39 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] startup script local admin password reset
A Description of the Network Configuration Operators Group:
http://support.microsoft.com/kb/297938
Members of the Network Configuration Operators group cannot create a new
connection for all users in Windows XP:
http://support.microsoft.com/kb/909347
I started with the Secretaries that were surfing on Myspace. Management
goes for that. Work your way up the food chain.
Al Mulnick wrote:
> Yeah, where'd I get the obscurity part? Hmm...
>
> "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."
>
> Why is that so difficult really? You say it's a headache, but why is
> it a headache to have such a system?
>
> And I never said that you could not run in a reduced administrative
> mode. Just make it so my users can control what they need to with
> non-admin privs to be workable and I'm fine with it. Laptops too :)
>
> Oh, and invent that time machine and make my past ISV's fix there
> stuff to work with the future of computing and I'll be able to let it
> work. Susan's comments aside (no disrespect, but that's not always
> worked nor has adding/removing drivers for some users that are in
> remote locations where technical supply is not available - that needs
> to be fixed still.) And fix the OS so that users can install printers
> and network cards and usb devices without administrative rights. The
> ones they buy from some big box store. That seems to save the company
> money for the home office users. Go figure.
>
> If you've found a way to allow that installation and removal process
> to work, and the network to work properly (XP introduced some groups
> that allow some network control) let me know. I'm happy to
> investigate. Susan, that includes you too since you're lurking....
>
> To date, I have not found a feasible solution nor a time machine.
> Either would be fine by me.
>
>
> Al
>
>
> On 6/26/07, Austin Osuide wrote:
>>
>>
>>
>>
>> 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.
>>
>> ________________________________
>
>>
>>
>>
>>
> .+- w i 0 - + ֬ @Bm + v* ˊ E ֫r zm + v* k ^} )x===
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
|
|