Accessing Azure Active Directory Domain Services nTSecurityDescriptor via LDAP

Note on 1/8/2021: Yes it's possible to update the DACL part of security descriptors, which means the statement on that subject in the page is incorrect (not surprising because the statement was an assumption without any experimenting)

The Experiment

After creating the embedded OUs on the Azure Active Directory Domain Service (AADDS), next step is to retrieve the OU from the server using ldap.

So I created a ubuntu 18.04 VM on the same VN and subnet as the domain service, and installed ldap-utils on the vm. Then I ran the following command:

yma@ymavmlinux1:~$ ldapsearch -h mitbbs888.onmicrosoft.com -D [email protected] -w xxxxxxx -b ou=ymafiles,ou=files,dc=
mitbbs888,dc=onmicrosoft,dc=com
# extended LDIF
#
# LDAPv3
# base <ou=ymafiles,ou=files,dc=mitbbs888,dc=onmicrosoft,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# YmaFiles, Files, mitbbs888.onmicrosoft.com
dn: OU=YmaFiles,OU=Files,DC=mitbbs888,DC=onmicrosoft,DC=com
objectClass: top
objectClass: organizationalUnit
cn: Yanrui Ma
ou: YmaFiles
distinguishedName: OU=YmaFiles,OU=Files,DC=mitbbs888,DC=onmicrosoft,DC=com
instanceType: 4
whenCreated: 20200602222513.0Z
whenChanged: 20200603182352.0Z
uSNCreated: 41559
uSNChanged: 60581
name: YmaFiles
objectGUID:: oS2fOua1U0OI7mC10GHS+A==
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=mitbbs888
 ,DC=onmicrosoft,DC=com
dSCorePropagationData: 20200602222513.0Z
dSCorePropagationData: 20200602222513.0Z
dSCorePropagationData: 16010101000000.0Z

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

As you can see, the nTSecurityDescriptor field is missing. If you remember, the admin1 user is a member of the "AAD Domain Administrators" group. So it's kind of unexpected for it to not be able to return the nTSecurityDescriptor attribute.

Then I tried with a regular user who isn't in the administrators group, and the user is able to retrieve the same amount of info. Which means being part of the group doesn't help with this aspect.

In this article, https://www.chadsikorra.com/blog/parsing-the-ntsecuritydescriptor, author suggests setting an server control to tell the search to not return the "SACL" (System ACL) part of the descriptor. User and group permissions are stored in "DACL" (Discretionary ACL) so retrieving only DACL (along with some other info) is enough for checking permissions.

So I created a small util ldaptest by modifying an ldap search example with source, and indeed, when the server control is set, nTSecurityDescriptor is returned

yma@ymavmlinux1:~$ ./ldaptest -D [email protected] -w xxxxxx -H ldap://mitbbs888.onmicrosoft.com/ou=ymafiles,ou=files
,dc=mitbbs888,dc=onmicrosoft,dc=com -O
# whoami: u:MITBBS888\admin1
# 1 entries found.
dn: ou=ymafiles,ou=files,dc=mitbbs888,dc=onmicrosoft,dc=com
[objectClass 3]: top
[objectClass 18]: organizationalUnit
[cn 9]: Yanrui Ma
[ou 8]: YmaFiles
[distinguishedName 55]: OU=YmaFiles,OU=Files,DC=mitbbs888,DC=onmicrosoft,DC=com
[instanceType 1]: 4
[whenCreated 17]: 20200602222513.0Z
[whenChanged 17]: 20200603182352.0Z
[uSNCreated 5]: 41559
[uSNChanged 5]: 60581
[nTSecurityDescriptor 1784]: 
[name 8]: YmaFiles
[objectGUID 16]: -:SC`a?
[objectCategory 84]: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=mitbbs888,DC=onmicrosoft,DC=com
[dSCorePropagationData 17]: 20200602222513.0Z
[dSCorePropagationData 17]: 20200602222513.0Z
[dSCorePropagationData 17]: 16010101000000.0Z

Since the field is binary, it's not being displayed properly, but we can see its length is 1784 bytes. And interestingly, the user that is not in the admin group now is also able to get the attribute.

I haven't tried setting the security descriptor, but I'm almost certain it will fail, because setting it means setting everything, including SACL.

It's a bit puzzling that making the user part of "AAD Domain Administors" group doesn't seem to help with retrieving info over ldap protocol. I also tried adding all the available administrative roles to the user, and also created a custom role with all the available permissions, but that didn't help either. With non-cloud version of Active Directory Domain Controller, the domain administrator is able to retrieve the whole nTSecurityDescriptor, including SACL.

Updating the nTSecurityDescriptor is needed for permission manipulation to work. Of course if there's a Azure functionality or tool that would allow us to set the permissions (and update the nTSecurityDescriptor) that'll work as well. But I haven't seen anything like that yet.

Possible Explanation:

In this link (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance-advanced) it did mention this:

"You don't have Domain Administrator or Enterprise Administrator permissions on a managed domain using Azure AD DS. These permissions are reserved by the service and aren't made available to users within the tenant. Instead, the AAD DC Administrators group lets you perform some privileged operations. These operations include belonging to the administration group on domain-joined VMs, and configuring Group Policy."

My question is, is there a way for an application or service principal to somehow get delegated this "Domain Administrator" permission?

These 2 questions in the FAQ page (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/faqs#can-i-add-domain-controllers-to-an-azure-ad-domain-services-managed-domain) seem to be relevant:

Can I add domain controllers to an Azure AD Domain Services managed domain?

"No. The domain provided by Azure AD Domain Services is a managed domain. You don't need to provision, configure, or otherwise manage domain controllers for this domain. These management activities are provided as a service by Microsoft. Therefore, you can't add additional domain controllers (read-write or read-only) for the managed domain."

Do I have domain administrator privileges for the managed domain provided by Azure AD Domain Services?

"No. You aren't granted administrative privileges on the managed domain. Domain Administrator and Enterprise Administrator privileges aren't available for you to use within the domain. Members of the domain administrator or enterprise administrator groups in your on-premises Active Directory are also not granted domain / enterprise administrator privileges on the managed domain."

Update 6/9/20:

Add OUs via ldap:

ldapadd -D [email protected] -h mitbbs111.onmicrosoft.com -w xxxxxx -f addou.txt

The content of addou.txt:

dn: OU=Files,DC=mitbbs111,DC=onmicrosoft,DC=com
objectClass: top
objectClass: organizationalUnit
ou: Files
distinguishedName: OU=Files,DC=mitbbs111,DC=onmicrosoft,DC=com
instanceType: 4
name: Files
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=mitbbs111
 ,DC=onmicrosoft,DC=com

ldapadd -D [email protected] -h mitbbs111.onmicrosoft.com -w xxxxx -f addou2.txt

Content of addou2:

dn: OU=yma,OU=Files,DC=mitbbs111,DC=onmicrosoft,DC=com
objectClass: top
objectClass: organizationalUnit
ou: yma
distinguishedName: OU=yma,OU=Files,DC=mitbbs111,DC=onmicrosoft,DC=com
instanceType: 4
name: yma
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=mitbbs111
 ,DC=onmicrosoft,DC=com

Retrieving nTSecurityDescriptor via LDAP: