We Have An AD User We Can't Delete.

  • Thread starter Thread starter JayKay
  • Start date Start date
J

JayKay

We have a user that was created then subsequently
deleted. Almost. If you go into the Win2k AD snap in,
the user is no longer there. If you go to Start |
Programs | Exchange | AD snap in, the user is listed
there with "unknown" attributes. Odd, as I thought the
AD snap in was the same no matter where you accessed it
from the Start menu. Is this not true?

When you try to delete the object, you get "the specified
directory service attribute or value does not exist".
I've read the KB that refers to this problem and I'm
logged in as Admin and have the permissions required.
One thing to note though is that if you go to properties
in the Exchange AD snap in, you can't get any
permissions/ownership properties on any objects. The
only tabs you see are "General", "Managed By", and "Group
Policy".

In any case, I'm at a loss how to get rid of this User
object. It needs to be recreated with the same name, but
obviously, this is not currently possible. Has anyone
run into this problem before?

Let me know if you need more info. Thanks in advance.

Jk
 
If the object continues to appear, I'd suggest trying to remove it using
ADSIEDIT (Start->Run->ADSIEDIT.MSC). Once ADSIEDIT is open navigate to the
location of that file and delete it.

Please repost if this does not work or you see some other behavior.
 
We have tried that...

There are 2 servers w/ AD... call them ex (exchange) and
dc (domain controller)... BOTH have this file living in
it using ADIEdit... When we try to delete either one, we
get the following error: "The specified Directory service
attribute or value does not exist"

As a side note, when looking in the exchange system
manager at the mailboxes, the mailbox store exists, and
when you run mailbox clean-up, it still shows it as being
attached to the user account (it is not orphaned).

-Scott
 
Hi Scott-

It might be a good idea to use DSACLS.EXE to export the ACL of that
object(s) and see what is says.

Another thought, if something surprising is found in the ACL, would be to
use the DSACLS /S switch to restore that object's default security entries
per it's schema class definition.

Please repost to let us know what you find.
 
Tim-

Here is what we are running on the user account, and when
we do the /S, we get the error below...

<SNIP>
C:\DOCUME~1\ADMINI~1.DOR\Desktop\SUPPOR~1>dsacls CN="XXX
XXX ",OU="XXX XXX",DC=XXX,DC=XXX,DC=XXX /S
The directory cannot be removed.

The command failed to complete successfully.
</SNIP>

We have removed the username, but if you run it w/o the
switches, you get the full permissions list...
Administrator(user) and Administrators(group) have Full
Control, and i am logged in as the administrator...

Thanks for your time, and help.

-Scott
 
I beleive that there is a Deny permission that may be coming into play here.
The obvious place(s) to look are the object itself and the container it
resides in. So, if you use DSACLS to list the permissions on those objects,
do you see any Deny permissions at all?

It's also possible that the Deny is at a higher level, such as on the
domain. It may be a good idea to check the parent containers as well, up to
the domain level, for explicit denies. If they are there, let's temporarily
remove them for testing purposes, or do a DSACLS <DN> /S /T to get them back
to defaults.

Please let us know if that helps or not.
 
No, as we don't want to reset the permissions for
everything. Are there any other options?
 
What kind of object is it that you're having trouble with? Is it a
container (does it contain other objects)? Regardless, you can use the
command below without the /T switch, which should make take the security
descriptor of that object back to schema defaults.

If the problem with deleting the object is due to securtiy this should help.
If this does not help, perhaps we can consider looking at the object's
metadata for obvious problems.
 
Back
Top