Just getting back to this thread and having a chance to write up some thoughts. It's splintered some, I'll go from here, because it seems to be a good place to fork this mail from.
A bunch of points worth commenting on: > I would like MS to put out guidance on making services with self > setting passwords as well as any services they have that require > userids doing the same. Yes, we know, and we're working on such things. We're also working on how to better manage such passwords going forward. > Additionally there are more forests > and domains in that company than probably any where else. > Many of them probably make sense like for the Windows groups working > on the AD product, but I expect many of them don't make any sense, > it is just people who want their own and want control over > "their own" machines so make them and use them. Joe, no such forest mayhem exists. All of our production forests exist for the purposes of testing scenarios and gaining confidence in alpha/beta grade bits before going full production with them. And there are fewer forests here than I would actually expect, and then I think you think there are. There are many untrusted forests, much like you might have "a forest" running on your desktop in virtual machines. But they don't really count, I was speaking more to production forests that are trusted by the core production environment. The # is not huge in the production boat. But that said, this all seems like a diversion from the original issue? Getting back to the original issue, on secure resetting passwords of local machines more generally.... This comment was made: > I used to store the password in the batch file before I got my brains > bashed out on this list. So, I went back and store the password in a DB, > read it on the fly from a vbs and pass it onto bat. This approach does not make it fundamentally better than sitting naked in a .bat file, though it does remove the low hanging fruit, a little. The question is, _under what security context_ does this VBS run (which answers the question, what context do I need to compromise to get the password?) and where is that password shared? If it runs as local system on a workstation, that implies that local system can read the password -> if I become local system I can read the password -> if I am admin on the machine I can read the password. This is just as concerning to me, depending upon the implementation. One implementation detail that could make this interesting would be if your db handed out a unique password to each workstation, and no workstation security context could read the password for any other workstation (record-level security could be used). Then you have limited my knowledge to the scope of what I already own....I can only read a password I don't care about, because I already own that box. If that's how you do it, you've solved part of the problem. Read below for more generic commentary on why this, especially bullet 2. If you want to test my ability to do this, give me admin on one of your boxes one day (and a kernel remote too, just in case I feel like being fancy), and I can try and obtain your password. I'd bet you a lunch (to be settled next time you're in the Seattle area) that I can get it. Fundamentally, to me, there are a few issues that need to be overcome in any solution I'd personally consider secure end to end: - You need to securely send the password to the machine, else a network sniff will reveal it - You need to establish trust boundaries within your environment, and not overlap password usage across such boundaries (nor ability for a machine in one realm to read the password in another realm). That is, if you have MachineA and MachineB, and you don't assume that anyone that is admin over MachineA should be admin over MachineB, you should not use the same password on both of them. Else compromise of one of them compromises both of them. In reality, this probably is best implemented with every machine having a unique local admin password. Why is this concept of boundaries so impt? Because there's really no trusted way of setting the password on a given machine and using it w/o exposing it to someone that has compromised that box. So no matter how you store, how you use, etc.....someone who owns that box will own that password. It might not be true, but it could be, so you should assume it. That takes us to the place where, unique passwords for trust realms are required. - You need to securely store the passwords of the machines before, during, and after they have been used. - You need to have a mechanism by which you can "check out" passwords to people that need them such that you know A) who has gotten the password to a given machine B) when they got it C) when they are done with it and D) a mechanism to reset that password so that the knowledge of the local admin password in question is not forever-lasting after a single checkout. - Of course, the obvious....passwords should be complex, long, etc. This list is by no means complete, but it's enough to get the ball rolling, and to put a project spec together that others can poke holes in. Bullets 2 and 4 are, to me, what take us from a mediocre to a good solution. My $0.026269 (Australian) ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, May 05, 2005 7:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] GPO not applied - thinks it is empty Completely in my opinion.... MS is not like most companies, especially most big companies. It seemed to have been run in the past like a series of small companies with a lot of loosely connected stuff. Sort of a federation versus a united whole. I have watched this pretty closely for a long time as I was always curious about the massive communication issues I had seen with and within MS. One extremely funny case was the fact that I used to ask the same question to like 2 or more groups all servicing the same widget company I worked for. These people were all part of MS but were obviously in very different parts of MS and were very disconnected internally, they did more bridging when in our meetings at our locations than when in theirs in my opinion. It took them a couple of years to come to the realization that I was asking the different groups the same questions and weighing the answers against each other and at times, letting them battle each other with their answers with them never knowing they were battling other MS folks. And it wasn't like these were small questions either, I don't often ask small simple questions, these were mostly deep difficult questions and the radically different opinions that came back showed the cracks. Anyway, we ran into several issues with Exchange as I have often hinted at and they were issues that they should have been hitting internally, until I found out they had such a disjoint internal configuration. Later I found out they had started collapsing the structures and pulling things back to more central locations and started hitting a lot of the same issues we had been pointing out for some time that we had been told were due to our design not due to any lacking in Exchange... It is just a guess, but I expect most everyone if not everyone has full admin of their workstations and servers. Additionally there are more forests and domains in that company than probably any where else. Many of them probably make sense like for the Windows groups working on the AD product, but I expect many of them don't make any sense, it is just people who want their own and want control over "their own" machines so make them and use them. I think the power and reach of ITG/OTG/GOAT or whatever it is called now is growing in the desktop space but I am not sure how much power they have over the admin ID. They almost certainly have enough deployment mechanisms through AV software and SMS on the corporate standard workstation load that they have multiple paths into boxes through localsystem so knowing the admin ID at any given moment probably isn't all that important. Well it isn't that important anyway as we all know, if you want into a box, you get it in front of you and insert a cd and you are on. If MS is going to work on issues with IDs at all, I would ask that the focus be put on Service IDs and how services work in general or mechanisms to help easily change passwords of service IDs. So many companies run around with non-expiring service IDs not realizing how insanely insecure that is. Heck, MS themselves was hacked because of unchanged service IDs several years back and I recall hearing how billg had put out a message that they were going to stop using non-expiring accounts. I expect that dropped by the wayside because we haven't seen many new ways of handling services (though I do say thanks for localservice and networkservice). Think about all of this logically.... You force password changes so that a password can not be the same thing for long enough to hack it through various brute force methods or because it has been the same too long and you don't know who all has the password now. So then you take IDs that are more likely targets for hacking than normal IDs due to usually having more power/rights and being known by multiple people so there is always question as to who did what and then you make them non-expiring and let them stay unchanged for a year or more. What brain dead security people are making those decisions? They just made a mockery of all their other decision making processes for setting a password change policy in the first place. If anything, service IDs should be changed more frequently than normal user IDs. The number one argument I hear about having non-expiring IDs is that the password needs to be changed in a controlled fashion, it can't just be allowed to expire... My response to that is always... Fine, change it in a controlled fashion, you know exactly when it is going to expire, make sure you change it before then. This gets fought and it goes to policy/security people who say, ok, we will grant a non-expiring password but you have to change it every X days!!! How many people grant non-expiring IDs to application owners who say they will change their password at least every X days? Raise your hand. How many actually go back and audit those same IDs and shut them down if the password is older than that X days? Raise your hands. I expect the first number of hands far exceeds the second number. Who wants to take responsibility for knocking down a running application? This is the kind of thing I get fired for because I will take that responsibility, I think it is more important that they be secure because I know the minute they are compromised they are going to chew me out asking who did it and how. I have seriously had managers ask me who logged onto a specific ID. My response... Well whomever has the password of course! No, specifically who logged on and did this. My response... I don't know, the mechanism I have for tracking the WHO is completely compromised by how you use the system with that ID. For a small fee, we can install a web cam on every machine in the world that people can log into and we can work out a mechanism around that if you would like to track it the next time your application gets hacked..... Anyway... :o) I would like MS to put out guidance on making services with self setting passwords as well as any services they have that require userids doing the same. If people write services they can do that now but many don't because they think... Well crap I have to store the plain text password somewhere... If the ID is a domain ID, don't do it that way, give the service ID the ability to SET its own password. Then it can randomly generate a password once a day, once a week, once a month and set it. Now the issue, from what I understand, is that the service has to be restarted... I would like to see a mechanism that makes this so it isn't required. I expect it is possible, users do it now when they change their password interactively. While it is a troubleshooting good idea to log off and log on, it isn't always required. It should never be required. Changing local machine IDs is much harder if the ID isn't an admin itself on the machine in question. Those currently would have to remember the old password. But the question is... If you have a local ID for a service... Why does it have to have a password at all? Why can't it be a service only password that you get to specifically set the rights for (i.e. not use localservice which applies to all services running as localservice). I would like to see a similar domain ID as well so people don't have to be stuck with networkservice or a regular ID that needs changing. That one is a little tougher to overcome though. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, May 05, 2005 9:30 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] GPO not applied - thinks it is empty I used to store the password in the batch file before I got my brains bashed out on this list. So, I went back and store the password in a DB, read it on the fly from a vbs and pass it onto bat. What's taking you guys so long to give us a more elegant solution for this "must-have"? Until you do, all we have is crud and we balance the security of the implementation against the URGENT need for this feature. If you are savvy enough to fire up a sniffer to get the info or know where to go to get it raw, you are more than a casual threat as far as I'm concerned. In that situation, I'll let HR deal with you as soon as I find out (IF I find out). How does MS IT do it? Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of Eric Fleischman Sent: Wed 5/4/2005 12:09 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] GPO not applied - thinks it is empty If I could ask what might be the obvious, from a security perspective.... If you have a policy out there resetting the local admin password, how are you storing the new password in the script? Hopefully you have something very clever in place, else I can get the local admin password out of your policy in so many ways: * If you didn't consider this at all, I bet the policy is ACLd with AU having read, so I can just read it out with notepad. * If you were clever enough to acl the policy so that only the machine accounts can read it, I could own a machine (perhaps I already do....perhaps I am in the local admins group on one of the boxes, because it is _my machine_) and just open the policy while impersonating the machine. Or get the machine to do it for me (since I own it, I can make it do my bidding). * <etc> And if you haven't taking precautions, you should assume local admin on any machine with this password is local admin on them all. For it only takes one bad apple to spoil the whole bushel. ~Eric ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Casey Sent: Wednesday, May 04, 2005 11:11 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] GPO not applied - thinks it is empty Thanks Darren- I ran the gpotool as you suggested. As part of the output I am told: Error: ServerName1 - Servername2 sysvol mismatch AND DC: Server2 Friendly name: server2 Created: 10/7/2004 Changed: 5-4-2005 5:34 pm DS Version 0<users> 37<machine> Sysvol: 0<user> 37<machine> Flags: 0 User extensions: not found Machine extensions: ..... Functionality version: 2 All fo the functionality versions are 2. Thanks, Brenda ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Wednesday, May 04, 2005 9:44 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] GPO not applied - thinks it is empty Brenda- This usually means that the client is looking at the GPO's version number and it is showing up as 0 for computer revisions (in other words, it doesn't think any computer policy has been set in that GPO). Run gpotool.exe (from Win2K reskit or part of XP and 2003) against your DCs and see if any of them show a revision number of 0 for the computer side of the GPO containing your script. This could still mean that you have some issues with sysvol replication. Essentially, there is a file called gpt.ini that is stored with the GPO in sysvol on each DC. This file contains a version number that lists how many changes were made to the computer and user sides of a GPO. That version should be the same as the version of that GPO held on the versionNumber attribute of the GPC object in AD. If there are discrepancies, then gpotool will tell you. Darren ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Casey Sent: Wednesday, May 04, 2005 7:21 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] GPO not applied - thinks it is empty I am no longer having replication issues on any servers, however, now when I run gpresult I am told that my gpo was not applied because it is empty. I can manually open the GPO and see my startup script is there. Thanks, Brenda ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Casey Sent: Tuesday, May 03, 2005 3:04 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] administrator password change in Startup script in GPO I have created a startup script to change my administrator password on specific machines as part of my group policy. These computers are part of a group, I have applied the policy to this group, and set the security permissions appropriately. When I run gpupdate on the pc, I get no error in the Event log, but when I restart the machine, the administrator account password has not been changed. I have run replmon.exe and have found that 1 dc (out of 30) is not replicating, as it is out of hard drive space on c:. Could 1 out of 30 dc's be causing the problem, or is there something else I am missing? How long should it take, before the policy takes effect? Thanks, Brenda List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
