Corrupted object in AD?

Thanks guys. I apologize, /resetDefaultDACL and /resetDefaultSACL only work
in ADAM now. I added this so long ago, I thought it was also in w2k3. But it
is not. It should be in Longhorn though.

The idea is to tell DS that you are setting the DACL (or SACL) via SD flags
control, but pass in an SD value without DACL (SACL) present. That would
indicate the intention to reset to default, to be performed on the server,
which is a more correct way than expanding the SDDL string on the client
(that's how /S works). So, this server-side reset currently works for ADAM
only.

BTW, both AD and ADAM support this functionality for OWNER field. Thus, if
you pass SD flags as 1 but your SD does not have an owner, then AD will
invoke the "SetDefaultOwner" procedure.

/takenOwnership should be /takeOwnership. Only the help text is wrong, the
actual flag is /takeOwnership. And they don't have to be upper-case, at
least not in ADAM's version of dsacls. I fixed the help text in ADAM SP1.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm

I've just noticed that I dropped the ADAM dsacls into a folder in the
path on my workstation. However I forgot that I have the Windows 2003
Support Tools on my PC and therefore I have the older version on my
system too. It's probable that I ran the wrong one.

They both have a typo in the help for the /takeOwnership
(takenOwnership) and it's not clear that they expect all options to be
in uppercase only.

"Dmitri Gavrilov [MSFT]" <dmit @online.microsoft.com> wrote in message < >...

I fixed it. The /S switch doesn't run if there is an Everyone:Deny
permission. I was able to remove this deny using:

dsacls <object> /R Everyone

at which point my problem was solved, since all the rest of the
permissions were as before and the correct Everyone permissions were
inherited from the parent object.

That's useful to know, thanks for following up. It looks like

http://support.microsoft.com/d efault.aspx?scid=kb;EN-US;3004 44

is the right approach for this problem.

Lee Flight

If I attempt to use /resetDefaultDACL with the ADAM version of dsacls
against an object in the AD I get:

C:\WINDOWS\ADAM>dsacls "cn=comp2,ou=TestOU,dc=test,dc­=net" /resetDefaultDACL

 Specified operation failed with ldap error:
         00000538: AtrErr: DSID-03150896, #1:
        0: 00000538: DSID-03150896, problem 1005 (CONSTRAINT_ATT_TYPE), data
0,
Att 20119 (nTSecurityDescriptor)

        Constraint Violation
.
The parameter is incorrect.

The command failed to complete successfully.

Even for an object on which the W2k3 dsacls /S returns OK. /takenOwnership
and /resetDefaultSACL all work OK.

Thanks
Lee Flight

"Dmitri Gavrilov [MSFT]" <dmit @online.microsoft.com> wrote in message

Interesting... I think I only now begin to understand why /S does not work,
while /R does. /S tries to reset the permissions to the default SD from the
schema. But that means it needs to read the objectClass first, and this is
denied. That's where it gets the error ERROR_CURRENT_DIRECTORY (The
directory cannot be removed). That's actually a bug -- it's actually getting
LDAP_NO_SUCH_ATTRIBUTE and converts it to a win32 error. Dsacls /R reads the
SD, and this is not denied for the owner of the object. Nor is writing the
SD.

That said, /resetDefaultDACL should have worked with ADAM's dsacls. This one
does not attempt to read anything.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm

< >...

< >...

Exchange,CN=Services,CN=Config­uration,DC=delta,DC=deltacomps­ys,DC=com"
Exchange,CN=Services,CN=Config­uration,DC=delta,DC=deltacomps­ys,DC=com" /S

It was the same problem as the original poster - I should have been
more clear. Someone had set the permission on the store, causing its
object at "Configuration/Services/Micros­oft
Exchange/Orgname/Administrativ­e
Groups/Sitename/Servers/Server­name/InformationStore/First Storage
Group/Storename" to have no class in ADSI Edit and to throw up the
error "An invalid directory pathname was passed" when you attempted to
open its properties.

I have the same problem with a mail store object. Someone previously
got in a mess with the Exchange permissions and it is currently
preventing exmerge from running (it enumerates the stores on startup
and quits).

I have tried everything in this thread and used the ADAM version of
dsacls.exe to no avail. I also get the "The directory cannot be
removed" error when I try the /S command line. I managed to take
ownership OK though. I have an Everyone:Deny All permission in there
just like the original poster.

Is there a solution to this?

Thanks,

Patrick

I don't know what happened to the original poster maybe he will
let us know. A couple of points: you talk about a "mail store object"
this is very different from the original poster, he had a messed up
permission
on an address list. You also mention exmerge, are you sure you are not
just running up against the default Exchange permission set where Admin
accounts
do not have permission to access mailboxes in the fashion that exmerge does.
If
you want to use exmerge you have to set up an appropriate group, see:

http://support.microsoft.com/d efault.aspx?kbid=292509

Lee Flight

<DomainName>\Enterprise Admins is the correct default owner
for that object (at least for Ex2k3 in the domain I am looking at).

Have you still got the deny Everyone permission in the DSACLS output
if not then you are OK aren't you?

Lee Flight

Hmm. First, make sure you are running ADAM's version of dsacls. The default
one lives in system32...
Try dsacls /resedDefaultDACL, it uses a slightly different mechanism of
doing this.

If this does not help, contact me offline (drop online dot).

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm

ERROR_CURRENT_DIRECTORY

Thanx, I really appreciate the help!  I downloaded the ADAM package and
installed the administrator tools only.  That gave me dsacls.  I ran it to
take ownership.  Here is the command line copy...

C:\WINDOWS\ADAM>dsacls "CN=All Users,CN=All Address Lists,CN=Address Lists
Container,CN=DeltaMa
il,CN=Microsoft
Exchange,CN=Services,CN=Config­uration,DC=delta,DC=deltacomps­ys,DC=com"
/takeOwnership

after dumping the ACLS it reported teh command completed successfully but
the owner was not changed, DELTA\Enterprise Admins.

I then tried running

C:\WINDOWS\ADAM>dsacls "CN=All Users,CN=All Address Lists,CN=Address Lists
Container,CN=DeltaMa
il,CN=Microsoft
Exchange,CN=Services,CN=Config­uration,DC=delta,DC=deltacomps­ys,DC=com" /S
The directory cannot be removed.

The command failed to complete successfully.

Same results as before.  The first tries were on the AD server itself logged
in as Administrator which is a member of Enterprise Admins.  I then
installed ADAM tools and tried the same thing on my box logged in as me, I'm
also a member of Enterprise Admins.  No difference...

Anything I'm doing wrong?  Any other ideas if not?  I do appreciate the help
guys!!!

"Dmitri Gavrilov [MSFT]" <dmit @online.microsoft.com> wrote in message

Aha, got it. We have bad error display there, it must be getting
LDAP_NO_SUCH_ATTRIBUTE == 16, and displaying it as ERROR_CURRENT_DIRECTORY
== 16. Silly...

You must have no access to the DACL. Download ADAM, install tools only and
use ADAM's version of dsacls to take ownership.

And follow Joe's advice re quotes.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm

Your DN is bad, you have quotes in all the wrong places.

That should look more like (excuse the wrapping).

dsacls "CN=All Users,CN=All Address Lists,CN=Address Lists
Container,CN=DeltaMail,CN=Micr­osoft
Exchange,CN=Services,CN=Config­uration,DC=delta,DC=deltacomps­ys,DC=com" /S

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Ah, they aren't converting the LDAP error to a Win32 error but directly throwing
the code through the Win32 error string formatting... That is a good catch D. I
am very impressed.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Here is the text from the command line:

C:\Program Files\Support Tools>dsacls CN="All Users",CN="All Address
Lists",CN="Address Lists C
ontainer",CN=DeltaMail,CN="Mic­rosoft
Exchange",CN=Services,CN=Confi­guration,DC=delta,DC=deltaco
mpsys,DC=com /S
The directory cannot be removed.

The command failed to complete successfully.

If I drop the '/S' I get a dump of the ACL which looks like what I expect.
If I change the '/S' to '/A' it says the owner is DELTA\Enterprise Admins
and the group is DELTA\Domain Users.

Thanx!

"Dmitri Gavrilov [MSFT]" <dmit @online.microsoft.com> wrote in message

Please paste the exact error message. "The directory cannot be removed" is
bogus. DSACLS does not try to remove any objects. Are you translating?

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm

Thanx for the response.  No question I shot myself in the foot - we all have
our moments I suppose.  I tried dsacls /S with no luck.  The response was
"The directory cannot be removed" and the command failed to complete
successfully.

Running dsacls without any options does display the acls on the object
correctly.  When I view the object in ADSIEdit it does not have a "class
type" - it is blank.  I noticed that /S restores it to its class type.  If
there is no class type what does dsacls do?  Is there a way to restore the
class type?

Any ideas?  Thanx!

"Dmitri Gavrilov [MSFT]" <dmit @online.microsoft.com> wrote in message

Class type (objectClass?) has nothing to do with the DACL. ADSIEdit has a
problem because adsi wants to read objectClass off the object, and
apparently you don't have access to that. Dsacls /s restores the default
DACL, but does not touch objectClass. Default DACL should give read access
to objectClass.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm

Any idea why I get an error when using dsacls /S - "The directory cannot be
removed"?  I logged onto the AD server as administrator which I assume is
the owner.

Thanx!

"Dmitri Gavrilov [MSFT]" <dmit @online.microsoft.com> wrote in message

Who does dsacls say the owner is if you run it as

 dsacls <DN of the damaged address list>

How does that output compare with that from another address list in your
address list container *and* is the Deny Everyone gone from that output?
--
I don't have access to an Exchange org at present (but we have had someone
do the same thing, it's easily done in Exchange) and so I can't check what
the default
owner is for an address list.

Also those Address List DN are pretty deep, are you sure that the container
is empty?

Lee Flight

Deny everyone means deny everyone, including you. You shot yourself in the
foot. To get out, you should reset the DACL to the default. You can use
dsacls /S to do this.

If you don't own the object, then this won't work. In this case, get ADAM
and use ADAM's version of dsacls. It has /takeOwnership switch that lets you
take ownership, which should give you WRITE_DAC control and you will be able
to update the DACL.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/ cpyright.htm