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: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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/
