cannot rename PC while it is joined

  • 183 Views
  • Last Post 15 May 2017
MatCollins posted this 08 May 2017

hello

there is a problem in our environments. since we have a strict naming convention, our help des must rename the computers which are not obeying the naming policies. although our help desk admins have local admin access on clients and they have control over computer accounts in AD, they recieve the below error:

"The following error occured attempting to rename the computer to XXX: Access is denied."

However, i am sure that there is no restriction, user has FC over computers and i can see that effective permissions are all Green. But again he gets access denied.

when i add the user to Domain Admins group he can succesfully rename the PC. so ,what is this? user has full access to PC and full access on computer object in AD, but why???

I found an error which might be related:

When I join a PC to domain, first it says welcom to domain, but after it shows an error below:

"Changing the primary domain DNS name of this computer to "" failed. The name will remain YYY.

The error was:

The specified server cannot perform the requested operation"

 

any ideas about it? it is really driving me mad! I guess there are something needs to fixed in DNS or AD. The local PC has no problem, because I can rename and join to another child domain with no problem, but one of the domains is problematic..

thank you

Order By: Standard | Newest | Votes
Cynthia posted this 08 May 2017

In the Default Domain Controllers Policy (group policy in AD) on your domain – add the group for your helpdesk (for instance 999ABC\helpdesk) to the add workstations to a domain

right.


It’s been a while but I think that’s the only you may need to affect.

 



Cynthia Erno



 

show

MatCollins posted this 08 May 2017

Its already done. The user can join to domain actually, but cannot rename the PC. Any ideas?

Anthony.Vandenbossche posted this 08 May 2017

Have you tried removing the Computer object and rejoining the domain from there?

 


ANTHONY VAN DEN BOSSCHE


Technical Consultant


Hybrid Cloud



You can mail me

anthony.vandenbossche@xxxxxxxxxxxxxxxx


Call me at my UC number +32 2 801 54 59



RD Portal



www.realdolmen.com



This e-mail message and any attachment are intended for the sole use of the recipient(s) named above and may contain information which is confidential and/or protected

by intellectual property rights. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have

received this e-mail in error, please notify the sender either by telephone (+32 2 801 55 55) or by e-mail and delete the material from any computer. Please note that neither Realdolmen nor the sender accept any responsibility for viruses and it is your responsibility

to scan or otherwise check this e-mail and any attachments.  Realdolmen is responsible neither for the correct and complete transfer of the contents of the sent e-mail, nor for the receipt on due time.



Think green, keep it on your screen

 

show

kool posted this 08 May 2017

You may need to ensure that members of this group have “create computer object” permissions on that OU. I believe this permission is necessary to do a rename.

It would certainly be necessary if the rename included a move between OUs.

 

As for the other error you are seeing, what version of the OS are these computers running? There was a bug in Win7 that prevented joining a domain and changing

the DNS suffix in the same operation. See

http://support.microsoft.com/kb/2659158.

 

    Eric

 

 

show

wallyworld2002 posted this 08 May 2017

It is my understanding that the access denied error is because a computer "rename" is really a delete followed by an add.  It is the delete that is likely causing the accessed denied error.  I believe that computer has to be deleted by the account that created it.
Kevin


show

Cynthia posted this 08 May 2017

https://serverfault.com/questions/83184/what-access-right-is-required-to-rename-a-computer

 



Cynthia Erno



 

show

rwilper posted this 08 May 2017

In addition, an access denied could be coming from having “Protect this object from accidental deletion” set. This triggers for LDAP moves and LDAP renames.

 

-Ross



 

show

MatCollins posted this 09 May 2017

not work.

i am sure user who renames has full control over that computer (AD ACL, local admin) and it shows error access denied. the 'protect from accidental delete' is checked off, no AV installed

is there any way to see what cuases access denied? the error pops up so faster than expected, it like 0.0001 second. as soon as i enter credential to rename, it says access denied, but when i enter domain admins, it takes some normal time and then says Succesful.

wha else can cause this.. i am searching through gpo, dns, ...

thanks

FAB posted this 09 May 2017

Hi,

 

It’s not clear for me what process are you following for renaming the computer, but I think changing it in the system properties alone won’t work unless you disjoin/rejoin

the domain. Did you try netdom computername? I successfully used it in the past for renaming domain controllers, and Microsoft says it also works for member servers, so I guess you should give it a try. Probably you need to install RSAT tools first, or run

the command remotely – not sure if this works though, never tried it myself.

https://technet.microsoft.com/en-us/library/cc835082(v=ws.11).aspx

 

--

Regards,

Adrian

 

show

MatCollins posted this 09 May 2017

we have thousands of computers and we do have a strict naming policy based for computers based on their OU.It happens that help desks join a computer with wrong name to the domain. Now, they should go to the client and rename the computer to the correct name. the PC should stay joined to the domain.

there is no need to join and rejoin to the domain, because once the user has local access and AD right on computer object, it should be able to rename the computer with no error. the problem is, we have done everything like AD acess, local access, unchecking protected from accident , ... but again it is access denied.

 

MatCollins posted this 09 May 2017

a couple of updates:

  • i found out that the fsmoroleowner attribute in CN=infrastructure was poiting to the wrong dc, so i ran fxfismo to point it to the appropriate dc.
  • then, viewing Netsetup.log file i found out that the rename process always point to a DC and not goes trough the rest of DCs. i shut down the DC to see if it locates to another DC but i saw that on the log it is always ointing to DC1. here is a log of netsetup.log:

05/09/2017 17:07:42:338 -----------------------------------------------------------------
05/09/2017 17:07:42:338 NetpValidateName: checking to see if 'MHK-DFG' is valid as type 1 name
05/09/2017 17:07:45:840 NetpCheckNetBiosNameNotInUse for 'MHK-DFG' [MACHINE] returned 0x0
05/09/2017 17:07:45:840 NetpValidateName: name 'MHK-DFG' is valid for type 1
05/09/2017 17:07:45:842 -----------------------------------------------------------------
05/09/2017 17:07:45:842 NetpValidateName: checking to see if 'MHK-DFG.contoso.com' is valid as type 5 name
05/09/2017 17:07:45:842 NetpValidateName: name 'MHK-DFG.contoso.com' is valid for type 5
05/09/2017 17:07:45:842 -----------------------------------------------------------------
05/09/2017 17:07:45:842 NetpChangeMachineName: from 'GOGOG' to 'MHK-DFG' using '(NULL)' [0x2]
05/09/2017 17:07:45:842 NetpChangeMachineName: using DnsHostnameToComputerNameEx
05/09/2017 17:07:45:842 NetpChangeMachineName: generated netbios name: 'MHK-DFG'
05/09/2017 17:07:45:842 NetpDsGetDcName: trying to find DC in domain 'contoso.com', flags: 0x1010
05/09/2017 17:07:45:983 NetpDsGetDcName: found DC '\\DC1.contoso.com' in the specified domain
05/09/2017 17:07:46:003 NetpChangeMachineName: status of connecting to dc '\\DC1.contoso.com': 0x0
05/09/2017 17:07:46:003 NetpGetLsaPrimaryDomain: status: 0x0
05/09/2017 17:07:46:021 NetpManageMachineAccountWithSid: status of NetUserSetInfo on '\\DC1.contoso.com' for 'GOGOG$': 0x5
05/09/2017 17:07:53:077 -----------------------------------------------------------------
05/09/2017 17:07:53:077 NetpChangeMachineName: from 'GOGOG' to 'MHK-DFG' using 'contoso.com\renacc' [0x2]
05/09/2017 17:07:53:077 NetpChangeMachineName: using DnsHostnameToComputerNameEx
05/09/2017 17:07:53:077 NetpChangeMachineName: generated netbios name: 'MHK-DFG'
05/09/2017 17:07:53:077 NetpDsGetDcName: trying to find DC in domain 'contoso.com', flags: 0x1010
05/09/2017 17:07:53:077 NetpDsGetDcName: found DC '\\DC1.contoso.com' in the specified domain
05/09/2017 17:07:53:131 NetpChangeMachineName: status of connecting to dc '\\DC1.contoso.com': 0x0
05/09/2017 17:07:53:131 NetpGetLsaPrimaryDomain: status: 0x0
05/09/2017 17:07:53:148 NetpManageMachineAccountWithSid: status of NetUserSetInfo on '\\DC1.contoso.com' for 'GOGOG$': 0x5

 

thanx for your help.

barkills posted this 09 May 2017

I’ve reviewed the past emails you’ve sent. In one of the later emails you said that the user which is having problems has local administrator permissions.



 

But not having local administrator would match some of the key reported symptoms:

-immediate access denied (only a local call to check if you have local admin perms)

-domain admin works (b/c it has local admin by default)

 

I assume that the account which is trying to do the rename has a fresh logon token (b/c if it got added to a group, but never logged in fresh, then that group

is not present in the logon token).

 

I have seen computer renames fail when the servicePrincipalNames values on the AD computer object do not correspond to the dnsHostname value. This most often

happens due to the Windows 7 bug Eric Kool-Brown mentioned, but I’ve seen it in a few non-Win7 cases. And there is another scenario I’ve seen which is similar—if the name the computer has does not match the name the AD computer object has, then you will also

be unable to rename. I haven’t heard any evidence that either of these scenarios are present. However, if it is the case, to fix it, you must manually fix up the AD values to match the local computer’s view of reality, and ensure that the SPN values correspond

to the dnsHostname value (I use LDP.exe, but ADSIEdit should work fine too), then you can successfully do the rename. I can provide more details here if this sounds promising.

 

Brian

 

show

barkills posted this 09 May 2017

A couple more thoughts:

 

-I wonder whether this rename problem is only with a single computer or with any computer in the domain. I think we’ve been assuming it is any computer because

you’ve implied that it is every computer, but I’m not certain—so I’d like to explicitly hear that you currently have this problem on more than one computer.

 

-Is the computer name change being attempted a netbios name change or only a DNS suffix change? Or both? You have not been explicit about which type of name change

is failing, and I think everyone has been assuming it is a netbios name change. And there is sufficient evidence in your first email to suggest it might only be a DNS suffix change. If it is a DNS suffix change problem, then there are a whole set of different

possible causes (including the AD attribute I hate more than any other—msDS-AllowedDNSSuffixes).

 

-You have not said how the “help desk” is trying to rename computers which are in violation of your naming policy. At least one person has asked about this, but

you have not responded to that question. I think this is a key detail which would help us to help you. Please give us more details on what specifically is being attempted which fails.

 

-In the first email you sent, you mentioned an error message after join--which is a key reason why I’m wondering if this is a single computer problem and also

why I am now wondering if this is a DNS suffix problem only. That error message makes me wonder about what happened on the computer before domain join. In my experience, if you rename a computer but do not permit the suggested reboot, and then join the domain,

you will get error messages like what you report in that very first email. And that can lead to a situation like the one I described, where the dnsHostname or SPN values are confused. If so, that computer will be in a state where it reports: “The

security database on the server does not have a computer account for this workstation trust relationship.”

 See



https://itconnect.uw.edu/wares/msinf/other-help/faq/ou-guidance/#fixDnsErrorViaPS for a FAQ I wrote which provides that greater level of detail I alluded to in my earlier email.

 

-Still focused on that error message you reported in the first email in the thread, I believe the primary DNS suffix is stored in a couple places locally. There

are registry key/values, but via past experiments I’ve tried, I think changing the primary DNS suffix is not as simple as changing the registry key/values—there’s something more—and perhaps it’s as simple as locked data that’s in active memory (which would

explain the reboot requirement). You might do a little research on those registry values and inspect them to see if they are as they should be. I would caution you against changing them manually though—when I’ve done that in the past, it never ends well—and

I end up needing to rebuild the computer.

 

-If the naming policy that folks need to comply with is only a DNS suffix issue, then there is a simple solution which does not involve anyone manually doing

anything for each violation—employ the group policy setting which can set the DNS suffix and trust that it will fix all existing and future violations:



https://itconnect.uw.edu/wares/msinf/other-help/faq/ou-guidance/#dnsSuffixViaGPO.



 

Brian

 

show

MatCollins posted this 10 May 2017

Thanks for the infor brian.. jeez that a lot of info, i dont know where to start, but:

  • all computers are affected, which means out help desk admins can not rename any computer at all.
  • i am sure that they are local admins on the pc and has FC access on computer objects in domain.
  • by rename, i mean they go to the computer locally, open sysdm.cpl and rename the computer. they are a group of 50 admins, so if you asking me if they go locally to clients and do the rename, yes they do it that way.
  • since the pc's are already joined to domain, the dns suffix of them are alreay populated. so the help desk admins go to clients, and change the netbiosname in sysdm.cpl. the rename should be an inplace rename meaning the computer should be stay joined to the domain.

i am assuming the dns part and the suffix part you said, is related to this rename process. because once a client is joined to the domain it shows the error i posted in my first post. i guess once this problem is solved, i am a step near to fixing this rename process.  so i think it is good to focus on that first.

also in one of the computer where they cannot rename, i saw dfsr-234234-6-2-234-1212/PC.contoso.com as serviceprincipalname. do you think it is related? 

 

MatCollins posted this 12 May 2017

I am near to clueless now.. is there any information which i can provide to find my problem?

thank you

barkills posted this 12 May 2017

I think this would be useful:

 

Get-adcomputer <computername> -properties *

 

And

 

Get-adcomputer <computername> -properties ServicePrincipalNames | select-object –ExpandProperty ServicePrincipalNames

 

And

 

(get-acl 'AD:<DN of computer>').Access | ft IdentityReference,AccessControlType –A

 

For the first two, you simply supply the netbiosname.

For the last one, you can use the output of the first command to get the DistinguishedName, and then plug that in.

 

This info may not turn up anything, but it would help eliminate a bunch of possibilities.

 

show

MatCollins posted this 13 May 2017

thanks, here are the reports that were wanted:

 PROPERTIES

AccountExpirationDate :
accountExpires : 9223372036854775807
AccountLockoutTime :
AccountNotDelegated : False
AllowReversiblePasswordEncryption : False
AuthenticationPolicy : {}
AuthenticationPolicySilo : {}
BadLogonCount : 0
badPasswordTime : 0
badPwdCount : 0
CannotChangePassword : False
CanonicalName : ad.contoso.com/System Manager/Company/Computers/GOGOG
Certificates : {}
CN : GOGOG
codePage : 0
CompoundIdentitySupported : {False}
countryCode : 0
Created : 4/8/2017 1:49:33 PM
createTimeStamp : 4/8/2017 1:49:33 PM
Deleted :
Description :
DisplayName : GOGOG$
DistinguishedName : CN=GOGOG,OU=Computers,OU=Company,OU=System Manager,DC=ad,DC=contoso,DC=com
DNSHostName : GOGOG.ad.contoso.com
DoesNotRequirePreAuth : False
dSCorePropagationData : {5/13/2017 12:05:19 PM, 5/13/2017 12:02:43 PM, 5/13/2017 11:04:51 AM, 5/13/2017 11:02:24 AM...}
Enabled : True
HomedirRequired : False
HomePage :
instanceType : 4
IPv4Address : 172.16.8.158
IPv6Address :
isCriticalSystemObject : False
isDeleted :
KerberosEncryptionType : {DES, RC4, AES128, AES256}
LastBadPasswordAttempt :
LastKnownParent :
lastLogoff : 0
lastLogon : 131388791154319988
LastLogonDate : 5/9/2017 11:25:56 AM
lastLogonTimestamp : 131387865568295569
localPolicyFlags : 0
Location :
LockedOut : False
logonCount : 14
ManagedBy :
MemberOf : {}
MNSLogonAccount : False
Modified : 5/13/2017 12:05:19 PM
modifyTimeStamp : 5/13/2017 12:05:19 PM
msDS-SupportedEncryptionTypes : 31
msDS-User-Account-Control-Computed : 0
Name : GOGOG
nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory : CN=Computer,CN=Schema,CN=Configuration,DC=AD,DC=contoso,DC=com
ObjectClass : computer
ObjectGUID : 1b9f841f-5f10-4537-8b3b-653866f0f1a8
objectSid : S-1-5-21-3632500116-4108935582-1686459859-35185
OperatingSystem : Windows Server 2012 R2 Datacenter
OperatingSystemHotfix :
OperatingSystemServicePack :
OperatingSystemVersion : 6.3 (9600)
PasswordExpired : False
PasswordLastSet : 5/9/2017 11:39:56 AM
PasswordNeverExpires : False
PasswordNotRequired : False
PrimaryGroup : CN=Domain Computers,CN=Users,DC=ad,DC=contoso,DC=com
primaryGroupID : 515
PrincipalsAllowedToDelegateToAccount : {}
ProtectedFromAccidentalDeletion : True
pwdLastSet : 131387873965625395
SamAccountName : GOGOG$
sAMAccountType : 805306369
sDRightsEffective : 15
ServiceAccount : {}
servicePrincipalName : {E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/GOGOG:24568,
E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/GOGOG.ad.contoso.com:24568, ldap/GOGOG:24568,
ldap/GOGOG.ad.contoso.com:24568...}
ServicePrincipalNames : {E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/GOGOG:24568,
E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/GOGOG.ad.contoso.com:24568, ldap/GOGOG:24568,
ldap/GOGOG.ad.contoso.com:24568...}
SID : S-1-5-21-3632500116-4108935582-1686459859-35185
SIDHistory : {}
TrustedForDelegation : False
TrustedToAuthForDelegation : False
UseDESKeyOnly : False
userAccountControl : 4096
userCertificate : {}
UserPrincipalName :
uSNChanged : 72539620
uSNCreated : 53610947
whenChanged : 5/13/2017 12:05:19 PM
whenCreated : 4/8/2017 1:49:33 PM

SPN

E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/GOGOG:24568
E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/GOGOG.AD.Contoso.Com:24568
ldap/GOGOG:24568
ldap/GOGOG.AD.Contoso.Com:24568
Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/GOGOG.AD.Contoso.Com
TERMSRV/GOGOG.AD.Contoso.Com
WSMAN/GOGOG.AD.Contoso.Com
RestrictedKrbHost/GOGOG.AD.Contoso.Com
HOST/GOGOG.AD.Contoso.Com
TERMSRV/GOGOG
WSMAN/GOGOG
RestrictedKrbHost/GOGOG
HOST/GOGOG

 

ACCESS

IdentityReference AccessControlType
----------------- -----------------
Everyone Deny
NT AUTHORITY\SELF Allow
NT AUTHORITY\Authenticated Users Allow
NT AUTHORITY\SYSTEM Allow
BUILTIN\Account Operators Allow
AD\Domain Admins Allow
Everyone Allow
NT AUTHORITY\SELF Allow
NT AUTHORITY\SELF Allow
NT AUTHORITY\SELF Allow
BUILTIN\Print Operators Allow
BUILTIN\Windows Authorization Access Group Allow
AD\Domain Admins Allow
AD\Domain Admins Allow
AD\Domain Admins Allow
AD\Domain Admins Allow
AD\Domain Admins Allow
AD\Domain Admins Allow
AD\Domain Admins Allow
AD\Cert Publishers Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Servers Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserReadOnlyGroup Allow
CONTOSO\RTCUniversalUserAdmins Allow
CONTOSO\RTCUniversalUserAdmins Allow
CONTOSO\RTCUniversalUserAdmins Allow
CONTOSO\RTCUniversalUserAdmins Allow
CONTOSO\RTCUniversalUserAdmins Allow
AD\Sharepointadmin Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
AD\SECONDARYSITE$ Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
AD\Level1-OUAdmins Allow
AD\Level1-OUAdmins Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Servers Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Allow
AD\SECONDARYSITE$ Allow
CONTOSO\Exchange Windows Permissions Allow
CONTOSO\Exchange Windows Permissions Allow
AD\Level1-OUAdmins Allow
AD\Level1-OUAdmins Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
NT AUTHORITY\NETWORK SERVICE Allow
NT AUTHORITY\SELF Allow
CONTOSO\Organization Management Allow
CONTOSO\Exchange Trusted Subsystem Allow
AD\tqhadmin Allow
BUILTIN\Pre-Windows 2000 Compatible Access Allow
AD\SQLClusterUser Allow
AD\SQLClusterUser Allow
AD\Domain Computers Allow
CONTOSO\Enterprise Admins Allow
AD\Domain Admins Allow
BUILTIN\Administrators Allow

barkills posted this 15 May 2017

What looks like a smoking gun is in the details you sent on Saturday … I’ve reduced it down to the specific thing I’m referring to.   I’d look closer at that ACE. I’ll bet it is an inherited ACE as opposed to an explicit ACE. And that would explain why a domain admin (which has an explicit full control) would be able to rename but others with inherited allow ACEs can’t. For AD, explicit allow ACEs override inherited deny ACEs (where override isn’t actually what is happening—it’s more of an order of operations thing).

  This ACE may be what Ross suggested: “In addition, an access denied could be coming from having “Protect this object from accidental deletion” set. This triggers for LDAP moves and LDAP renames.” Personally, I hate that accidental deletion feature.   Brian

 

ACCESS IdentityReference AccessControlType
----------------- -----------------
Everyone Deny

Close