v2.10.1.0 Beta 3 issues from testing

[ralish]

Potential issues from a test scan against a production infrastructure using PingCastle v2.10.1.0 Beta 3.

Active Directory Indicators Typo in "Compare with statictics" button (should be "statistics").

AzureADConnect settings Title should probably be "Azure AD Connect"? Nothing listed in this section but the target domain does have a deployed Azure AD Connect server. Unclear if something is wrong, but if not, some explanatory text as to what's expected to be listed would be helpful.

Service Connection Points Nothing listed, however, the target domain is using Azure AD Password Protection and Azure AD Device Registration. Both of these features require the installation of an SCP into AD. Should these SCPs be listed? If not, it may make sense to add some explanatory text to this section covering what is and isn't expected to be shown.

[vletoux]

Can you send to support@pingcastle some screenshot about the following points to make sure the PingCastle algorithm is correct ? About AzureADConnect: it is based on domain replication right based on the root of the domain. Then to parse the description of the MSOL accounts

For service points there is a filter to make sure the serviceClassName is not empty:

Thanks for your quick feedback - the release will be published tomorrow or the next day

[ralish]

Hey there,

Thanks for the above! I'll get back to your regarding the SCPs but with respect to Azure AD Connect:

The referenced permission (DS-Replication-Get-Changes-All) is technically only required for the Password Hash Sync feature. If you're not using that feature it's not necessary, and depending on what features you have enabled a regular AD user account for the AD DS connector may be sufficient. The required AD permissions for the AD DS connector account are documented by Microsoft here.

It appears this permission is probably reliably present for AADC installations using Express settings, but in custom installations that definitely may not be the case. When the AD DS connector account is manually configured it can be setup with the minimum required permissions based on the features you expect to enable. This is officially supported and documented here.

I'm not sure there's a reliable way to detect the presence of Azure AD Connect in a domain? With a custom setup the connector account can have any name/description, and there's no Azure AD Connect specific permission. The only one that I think is near certain to be present is write access to the ms-DS-ConsistencyGuid attribute, but that permission may be assigned to other accounts or groups (e.g. Domain Admins), and may not be set on the domain root (e.g. only on specific OUs to limit AADC access to write the attribute only on accounts in synchronization scope).

In short, sadly I don't think an AADC installation can be reliably detected without a lot of false negatives.

[vletoux]

Or do you have a computer account with the description matching the regex ? const string regex = "^Account created by Microsoft Azure Active Directory Connect with installation identifier (?<identifier>.+?) running on computer (?<computer>.+?) configured to synchronize to tenant (?<tenant>.+?). This account must have directory replication permissions in the local Active Directory and write permission on certain attributes to enable Hybrid Deployment\\.$";

[ralish]

Nope, because in a custom configuration you can create the AD connector account yourself, then use the ADSyncConfig PowerShell module included with AADC to set the appropriate permissions based on intended feature usage. See here.

There's no reliable name or description in that case. I just inspected the user account properties in ADSI Edit and there's no account attributes which appear to be programmatically set which identify it as an AADC connector account.

[vletoux]

is the ms-DS-ConsistencyGuid write proterty right set on some OU ? There is a new section here about this rights (only DCSync for the moment)

[ralish]

Yes, but technically that's not required either as the ms-DS-ConsistencyGuid attribute doesn't have to be used as the source anchor. It's a kludge, but you could perhaps look for the combination of these permissions present on one or more OUs:

For example, from a production domain I administer:

The first AADC permission (with the blank Access property) should be ignored, as that's the ms-DS-ConsistencyGuid permission (i.e. may not be present). But if the others are present together on one or more OUs for the same account, I'd think there's extremely high probability it's an AADC AD DS connector account.

[vletoux]

I think this is too late for a last minute change (complexity is high and the delay is short due to the certificate expiration to come)

I'll propose to discuss this after a few days after the official release

[ralish]

Regarding the SCPs, I don't think filtering on the serviceClassName attribute alone makes sense. For the serviceConnectionPoint class it's documented as an optional attribute. The only mandatory attribute for the class is cn.

I'd suggest perhaps displaying every instance of a serviceConnectionPoint class found in the directory under the Configuration naming context? The Common Name can be used as a fallback if there's nothing better available. In my case I have several SCPs under the Configuration naming context which correspond to operational services. None of them set serviceClassName.

One is for hybrid Azure AD join. There's a good blog post about its SCP here. The GUID (62a0ff2e-97b9-4513-943f-0d221bd30080) appears to be well-known, as it's the same in my case, and you could parse the keywords attribute on the SCP object to extract the Azure AD tenant ID (as a GUID) and name (as <something>.onmicrosoft.com). This is also a good indicator that AADC is probably present, given hybrid Azure AD join is effectively useless otherwise.

The other is Azure AD Password Protection for Active Directory Domain Services. This uses several SCPs (one per DC and several others). Some are under the computer objects where the agent or proxy is running, others are in the Configuration naming context under CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=.... I'm not sure what the best way to detect this one is, but if there's at least one serviceConnectionPoint object under that DN, either the service is installed in the domain and active, or it's stale data and should probably be removed.

[vletoux]

The hybrid information is already extracted (domain information section)

[ralish]

Good point, and glad it's shown, but I'd suggest there should still be an entry in the SCP section which reflects the fact that hybrid Azure AD Join is enabled due to the presence of the SCP added by AADC under the Device Registration Service CN.