Active Directory Issue

C

cooter

Gawd
Joined
Dec 2, 2004
Messages
872
The company I work for just upgraded our domain controller from Windows 2000 to 2003. After the upgrade two of our Active Directory Security Groups have been having the members cleared out on a nightly basis. Every morning I have to go in and add the users to the SG and it is getting annoying, especially to those who have to wait for me or IT to add the users back in.

I am not in IT and and didn't want to have to deal with this but because it has been about 2 weeks I figure I would see if i can figure it out.

Other info:
-I am a domain admin
-IT does not remember setting anything up to clear this out.
-We plan on upgrading the domain controller to 2008 soon but who knows when that will happen. We hope that will fix this.
 
Is there any replication occuring or do you just have one DC?
 
You could make sure all your FSMO roles are handled... it sounds like there might be a problem with the Schema Master or RID master.

Run this from a command prompt on the DC

Code: 
dcdiag /test:Knowsofroleholders /v

(as ND40oz mentioned, if you have multiple DC's, replication might not be working properly... execute: repadmin /showreps )
 
ok, I'll bite.. what group is it? Windows has some built-in restrictions on group membership, and AD will remove users who are placed in the groups (Remote Desktop users, etc).

And just curious.. why does a non-IT user have Domain Admin rights?
 
Fint said:
ok, I'll bite.. what group is it? Windows has some built-in restrictions on group membership, and AD will remove users who are placed in the groups (Remote Desktop users, etc).
Click to expand...

The Groups are "Sales-SG" and "Management-SG" which are not a standard windows group.

Fint said:
And just curious.. why does a non-IT user have Domain Admin rights?
Click to expand...

Because this non-IT user knows more about hardware then anyone in the building, builds and fixes many/most of the client computer issues (we build our high-end workstations instead of buying from an OEM), and knows who's ass to kiss to get the rights. In the long run it saves IT a ton of time giving me the rights, so a win-win.

Back on subject, here is the story from IT directly:

We have one DC. In AD, I have 2 security groups that clear their members every day (all members are removed and the group is left empty approx. every 12 hours). All other groups are fine…it’s just these 2. The problem started occurring when I ran adprep /domainprep and adprep /forestprep prior to adding our first 2003 DC. I also manually removed a failed 2000 DC from AD (using these instructions) right around this time. It may be a tombstoning issue from the failed DC but why delete the members of the group and not the group itself? Or is AD somehow restoring a previous (that is, empty) version of the group object?
Click to expand...
 
cooter said:
I also manually removed a failed 2000 DC from AD (using these instructions) right around this time. It may be a tombstoning issue from the failed DC but why delete the members of the group and not the group itself? Or is AD somehow restoring a previous (that is, empty) version of the group object?
Click to expand...


BINGO!

See my previous post. It will point to the problem.

I'm guessing when he seized the failed FSMO roles, he never reassigned them to a current server. A lot of times, things are fine for months... until you run out of RIDs or need to make an infrastructure change.

So, run the commands in my previous post, and let us know which FSMO roles are not assigned and we can help you assign those roles to current servers....


RID Master FSMO Role
The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for removing an object from its domain and putting it in another domain during an object move.

When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.

Each Windows 2000 DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. There is one RID master per domain in a directory.

Back to the top
Click to expand...
 
That’s not it. When I cutover the DC, I transferred all the FSMO roles to the new DC before retiring the old one according to these instructions (http://www.petri.co.il/transferring_fsmo_roles.htm). I’ve attached a text file which shows this.

Text:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\orladmin>NTDSUTIL
NTDSUTIL: domain management
domain management: connections
server connections: connect to server hgdc01
Binding to hgdc01 ...
Connected to hgdc01 using credentials of locally logged on user.
server connections: quit
domain management: select operation target
select operation target: list roles for connected server
Server "hgdc01" knows about 5 roles
Schema - CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
Domain - CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
PDC - CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
RID - CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
Infrastructure - CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
select operation target: quit
domain management: quit
NTDSUTIL: quit
Disconnecting from hgdc01...

C:\Documents and Settings\orladmin>dcdiag /test:Knowsofroleholders /v

Domain Controller Diagnosis

Performing initial setup:
* Verifying that the local machine hgdc01, is a DC.
* Connecting to directory service on server hgdc01.
* Collecting site info.
* Identifying all servers.
* Identifying all NC cross-refs.
* Found 1 DC(s). Testing 1 of them.
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-Name\HGDC01
Starting test: Connectivity
* Active Directory LDAP Services Check
* Active Directory RPC Services Check
......................... HGDC01 passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\HGDC01
Test omitted by user request: Replications
Test omitted by user request: Topology
Test omitted by user request: CutoffServers
Test omitted by user request: NCSecDesc
Test omitted by user request: NetLogons
Test omitted by user request: Advertising
Starting test: KnowsOfRoleHolders
Role Schema Owner = CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
Role Domain Owner = CN=NTDS Settings,CN=HGDC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=orl,DC=hgi,DC=com
Click to expand...

The other thing is if I had an orphaned or missing FSMO role holder, all sorts of problems would be occurring, not just these 2 security groups.
 
Is there anything in the event viewer that says at what time or what process is doing this?

The only ideas have have is that:
1. There is a rogue DC somewhere.
2. There's some sort of GPO connected to those Security groups or possibly the OU that it is a child of.
 
Keiichi said:
Is there anything in the event viewer that says at what time or what process is doing this?

The only ideas have have is that:
1. There is a rogue DC somewhere.
2. There's some sort of GPO connected to those Security groups or possibly the OU that it is a child of.
Click to expand...

Thanks a ton, This question was able to prompt our IT guy to look in the right place to fix the issue.

Thanks for everyone's help!
 
IT has no clue as to what they are doing if a non-IT has domain admin rights. How could IT chase down a problem if a non-IT is running amok with domain admin rights?

This is the root cause of the problem.
 
BrkDncr said:
IT has no clue as to what they are doing if a non-IT has domain admin rights. How could IT chase down a problem if a non-IT is running amok with domain admin rights?

This is the root cause of the problem.
Click to expand...

Yes and no. In a medium or large environment, as a general rule of thumb, you're right. That's the only way to keep order, there's too much temptation and lack of communication in a large environment. This situation would cause more trouble than it's worth. But on the flipside, it depends on the relationship that the OP has with IT and the size of the business and what the OP's specific role is. Just because it it goes against the grain with traditional IT policies/thinking doesn't mean it's wrong. It just means that there's one more potential hole that their IT staf has to deal with. It's their business. If it works for them, more power to them.

Personally, I couldn't think of that situation existing in my network, but I can see the potential attractiveness. Especially if there's a measure of trust between official and unofficial IT.
 
For me, the issue comes down to this; if the OP really knew what they were doing, they would work in IT. If they don't know what they are doing, then why should they have the ability to destroy the entire AD system? Its an issue of safety.
 
I still want to hear what the solution was or this whole thread is pretty pointless. :eek:
 
You must log in or register to reply here.
Back
Top