I have seen a few questions regarding if Azure AD Domain Services supports Remote Desktop Services (RDS) licensing services.

These questions mostly are around whether or not Per User license auditing reports are supported as this requires AD user attribute updates when the RD Licensing Server issues a per user CAL to the user. In Azure AD Domain Services user writes are only allowed from Azure AD itself, not within Azure AD Domain Services (where the user objects are read only).

This process IS supported as long as the administrator installing the Remote Desktop Licensing server role on the Windows Server host is a member of the Azure AD group “AAD DC Administrators” when they are installing the Remote Desktop Licensing server role. You can verify membership from within your AAD DS joined workstation with cmd:

whoami /groups

Once you have verified membership in “AAD DC Administrators”, after installation of the Remote Desktop Licensing role, you should find that the server’s Windows AD computer object has been added to the “Terminal Server License Servers” security group as shown below:

If this is not the case, verify that the security permissions on the “Terminal server License Servers” group show that the “AAD DC Administrators” group has the effective permission “Write Members” as shown below:

And on a user within AADDC Users OU, view security effective permissions for the Terminal Service License Servers group and verify it has read\write permissions on the following msTS user attributes shown below:

If you do not see this ACL entry for Terminal Server License servers, you should open a support case as this would be unexpected behavior. If the Remote Desktop Licensing Server computer object is not a member of the “Terminal Server License Server” group then you may find the following error in your Event Logs:

Log Name: System
Source: Microsoft-Windows-TerminalServices-Licensing
Event ID : 4105
Level: Warning
User: N/A
Computer: <computer name>
Description:
The Terminal Services license server cannot update the license attributes for user <user name> in the Active Directory Domain <domain name>. Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain <domain name>.
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs.
Win32 error code: 0x80070005

Once computer membership in Terminal Server License Servers group has been confirmed, you should find no issues tracking Per-user CAL issuance in RD Licensing Manager:

Viewing any user’s AD attributes after they were issued a per user CAL should show that the necessary license tracking has been successfully written to the user in Azure AD Domain Services:

A Per-user CAL license report should also successfully list these users:

I hope this clears up any questions around the compatibility

Occasionally we receive support cases from customers performing audits of their Azure AD Audit or Sign in logs and do not know what the service principal \ actor ” Microsoft Approval Management “ is.

After review with Microsoft product engineering teams it was confirmed this is a 1st Party Microsoft Service Principal for the following services and may be logged in customer audit logs during the operation of any of these services in your tenant.

1. Dynamic Groups
2. Self Service Group Management
3. O365 Group Expiration policy

Any of the operations performed by these services such as calculating group memberships, applying group memberships, performing group expirations etc.  will be logged in Azure AD audit logs as being performed by “Microsoft Approval Management”.  All of the operations performed by these services, are documented in the links above.

You can confirm this service principal is in your AAD tenant with the AzureADPreview PowerShell module and the following cmd

Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Approval Management'" | fl *

Where you should confirm that the PublisherName = “Microsoft Services” and you may find it listed with the AppID of “65d91a3d-ab74-42e6-8a2f-0add61688c74” or “38049638-cc2c-4cde-abe4-4479d721ed44”

UPDATE:

If this service principal is disabled you may experience strange behavior in the Azure AD Portal when trying to manage groups.

One example, if this service principal has been disabled by the AAD Global Administrator any operation on groups in the AAD portal may return an error : “Unable to complete due to service connection error. Please try again later”

If you receive this error, verify that the Microsoft Approval Management enterprise application has not been disabled.

1. Go to AAD -> Enterprise Apps blade : Enterprise applications – Microsoft Azure
2. Then browse to All applications Set filters to Application type = All Applications, Status = Any, Application Visibility = Any In search box type the appID 65d91a3d-ab74-42e6-8a2f-0add61688c74

3. Open this app’s properties Choose Enabled for users to sign in = Yes Hit Save

4. Then retry their group operation which failed

NOTE: You may also want to check for app ID 38049638-cc2c-4cde-abe4-4479d721ed44 to verify it is enabled as well.

UPDATE:
If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports

We have received a few cases in AAD Audit Log support topic around AAD audit logs showing a service principal named “Microsoft Substrate Management” has created users in their AAD tenant and they have no idea who this principal is.

UPDATE:
If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports

You can find this service principal in your tenant using AzureADPreview Powershell module and the following cmd:

Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Substrate Management'" | fl *

Where you should be able to confirm this is a 1st Party principal (PublisherName = Microsoft Services) with AppID = 98db8bd6-0cc0-4e67-9de5-f187f1cd1b41

After investigation, it was determined that the “Microsoft Substrate Management” service principal is a 1st party service principal used by Exchange Online during dual write operations to AAD. When for example a mailbox is created directly in Exchange Online, this service principal may show up in your audit logs as the actor who created the user account the mailbox will be assigned to.

More information on dual write operations in Exchange Online can be referenced at https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-improvements-to-accelerate-replication-of/ba-p/837218

For a better picture of the actor who initiated the request in Exchange Online, you will need to search the Office 365 Unified Audit Log in the timeframe of the activity via steps mentioned in the following articles:
https://docs.microsoft.com/en-us/office365/securitycompliance/search-the-audit-log-in-security-and-compliance#search-the-audit-log

Hope this helps someone!

The following are my notes for setting up SAML/WS-Fed identity provider (IdP) federation for Guest users (formerly known as Azure AD B2B Direct Federation) with a GSuite domain. The official documentation can be referenced at https://docs.microsoft.com/en-us/azure/active-directory/b2b/direct-federation.

UPDATE

A couple key points to highlight before you begin configuring SAML/WS-Fed identity provider (IdP) federation for Guest users , please review the different federation scenarios on Azure AD and GSuite Federation Scenario Notes before beginning to verify this configuration is right for your scenario.

• This feature has been renamed to SAML/WS-Fed identity provider (IdP) federation for Guest users.
• This guide is for configuring a federation relationship with a GSuite domain so that you can invite B2B Guest users to your AAD tenant when those users do not have their own Azure AD work\school accounts. It is NOT intended for configuring a SAML federated domain in your Azure AD tenant for SAML Authentication of your own GSuite users. For that process review Scenario 1 in Azure AD and GSuite Federation Scenario Notes
• Once the B2B External Identity SAML federation has been configured, you MUST invite the GSuite Users to your tenant via a B2B Guest Invitation by folllowing Add guest users to the directory Once invited, the guest users MUST visit one of the supported tenanted URLs such as https://portal.azure.com/resourcetenant.onmicrosoft.com as described in supported Sign-in endpoints for SAML/WS-Fed docs . If they try to sign in via any other method (for example IDP initiated sign in) they will receive an error of the form ‘The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=xxxxxx’ does not exist.’ , meaning they tried to sign in to a common endpoint like https://portal.azure.com or https://myapps.microsoft.com.
• Note that if you only want to invite Gmail.com users you can use Google Federation steps instead https://docs.microsoft.com/en-us/azure/active-directory/b2b/google-federation

Steps to configure AAD B2B Direct Federation with GSuite Domain

1. Login to https://admin.google.com -> Security -> Authentication -> SSO with SAML Applications -> Download Metadata file
   
   

1. Choose Download Metadata, and save the returned GoogleIDPMetadata.xml locally
   
   

3. Browse to https://portal.azure.com -> Azure AD -> External Identities -> All identity providers -> New SAML/WS-Fed IdP .  Choose protocol = SAML, domain name = gSuite domain name, method = parse metadata file.  Browse to your GoogleIDPMetadata.xml file and hit parse, then save:
   
   

4. From https://support.google.com/a/answer/6363817?hl=en  follow Step 3. “Set up Google as a SAML identity provider (IdP)” and Browse to https://admin.google.com -> Apps -> SAML Apps -> New App

1. Filter existing apps by “Microsoft Office 365” and add the app
2. Download Metadata locally to .XML file
3. Save
4. Browse back to apps and choose “Microsoft Office 365”
5. Edit Attribute Mapping to be as follows
    
   

1. From https://support.google.com/a/answer/6363817?hl=en  follow Step 5. “Enable the Office 365 app” and Choose Edit Service -> Service Status -> ON for everyone

6. Lastly Invite the Guest GSuite domain User from Azure AD
   1. Now From Azure AD portal -> Invite New User -> Invite a user from G Suite domain
   2. G Suite user gets invite email, and clicks redemption link and signs in with G Suite credentials to redeem invite successfully

Finally, if needed you can manually configure GSuite Direct Federation using Azure AD Preview PowerShell module and example script below (note your GSuite metadata will be different)

Connect-AzureAD

$federationSettings = New-Object Microsoft.Open.AzureAD.Model.DomainFederationSettings
$federationSettings.PassiveLogOnUri ="https://accounts.google.com/o/saml2/idp?idpid=C01ypkxdy"
$federationSettings.ActiveLogOnUri = "https://accounts.google.com/o/saml2/idp?idpid=C01ypkxdy"
$federationSettings.LogOffUri = "https://accounts.google.com/o/saml2/idp?idpid=C01ypkxdy"
$federationSettings.IssuerUri = "https://accounts.google.com/o/saml2?idpid=C01ypkxdy"
$federationSettings.SigningCertificate= "MIIDdDCC_EXAMPLECERT_lMlRYzq4"

$federationSettings.PreferredAuthenticationProtocol="Samlp"
$domainName = "jfritts.xyz"

New-AzureADExternalDomainFederation -ExternalDomainName $domainName  -FederationSettings $federationSettings

We occasionally get support cases from customers who when browsing to their Azure Portal’s subscription blade see a subscription type with a strange name “Access to Azure Active Directory” and get strange errors like “Unknown” role or “Unauthorized” or “Unable to access data” or “The current subscription does not allow you to perform any actions on Azure resources. Use a different subscription.”

TLDR: These subscriptions do NOT host Azure AD. These are legacy subscriptions that can no longer be managed by customer portal. If causing issues they are safe to delete but can only be deleted via support ticket today. For more info read below details.

Examples:

History of the Access to Azure Active Directory subscription

The “Access to Azure Active Directory” subscriptions are a legacy subscription type that are no longer used.  They were used prior to the current Azure Portal (https://portal.azure.com). 

At that time the classic Azure portal (https://manage.windowsazure.com) that was used to manage Azure Active Directory and other Azure resources only allowed access if the user had a Azure subscription associated to their user account. It utilized the classic Azure roles such as “Subscription Admin” \ “Billing Admin” \ and “Co-Administrator” only so you had to have one of these roles in order to login. It did not take into account Azure AD roles like Global Administrator etc.

This caused issues when the Azure AD admin didn’t have an Azure resource subscription necessarily, so these “dummy” subscriptions were created for such access.
 
You can read this blog post for a bit more history if you are interested:  https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Azure-AD-Mailbag-Azure-Subscriptions-and-Azure-AD/ba-p/249661 which describes the need for these subscriptions and how admins would get one assigned to them when needed.

Today no such access subscription is required as we now separate AAD RBAC permissions (Global Administrator etc) and Azure Resource subscription RBAC permissions (Owner, Contributor, Reader etc) and do not limit user’s access to https://portal.azure.com.

How to delete the Access to Azure Active Directory subscription

If these subscriptions are causing you problems, or you would just like to cleanup your Azure environment from unneeded subscriptions you can get these subscriptions removed from your account by opening a support case and requesting the subscription be deleted. Unfortunately, as the errors suggest these subscriptions cannot be managed using the current Azure Portal.

These subscriptions do not host any data and removing them will have no impact to your Azure Active Directory tenant, data, users, groups, or other subscriptions.

Hope this helps someone!

While working with customers to enable LDAPS for their Azure AD Domain Services managed domain, we often have trouble performing a successful LDAPS Bind using the tool LDP.exe. Below are the troubleshooting steps to determine root cause.

Verify Network Connectivity

Always verify that the network connectivity to port 636 exists via DNS name and IP address before troubleshooting further.

1. Browse to https://portal.azure.com -> All Services (top left) -> Azure AD Domain Services -> <managed domain name> -> Properties blade. And verify the following attributes:

• Secure LDAP = Enabled
• Secure LDAP certificate thumbprint (copy and save for later)
• Secure LDAP certificate = Not Expired
• Secure LDAP external IP address

2. Download\Install PortQryUI

3. Open PortQry UI and perform a verification on the Secure LDAP external IP address on TCP port 636 to verify you see the port LISTENING.

If network connectivity doesnt exist, verify that the AAD DS Network Security Group (NSG) is allowing inbound traffic from client workstation to AAD DS subnet on TCP\636

4. Once network connectivity to the public IP of LDAPS on TCP\636 has been confirmed. Perform the same test, but use any DNS name you have registered for this public IP. Example: ldapstest.jasonfritts.me.

NOTE: The domain name will not necessarily resolve for an external client machine unless it has been registered by you or an admin manually. Example: jasonfritts.onmicrosoft.com will not resolve to my LDAPS public IP. I would need to manually register a record for ldapstest.jasonfritts.me to point to 137.117.71.1. For testing purposes in this example, I have updated my Windows HOSTS file to point jasonfritts.onmicrosoft.com to 137.117.71.1

5. Next verify that this certificate has been imported in the following locations on your workstation’s Computer certificate store

1. Open the certificates MMC snap-in to your Local Computer certificate store per instructions found here
2. Browse to the Trusted Root Certification Authorities\Certificates store and verify certificate with ”
   <aad ds domain name> ” is found listed.

You can also verify this via an administrative PowerShell cmd prompt and cmds like:

PS C:\ cd cert:\\
PS Cert:\> get-childitem -Path ’53F65017E5614959824FA5147A8173CAF8662D73′ -Recurse

If this certificate is not found in this location, please use the More actions -> Import action to import your self-signed AAD DS LDAPS certificate into the Trusted Root Certificate store of your Computer cert store and then retry your LDP.exe connection.

Until the self-signed certificate is trusted by your local computer, LDP.EXE will result in the error “Error: <0x51>: Fail to connect to jasonfritts.onmicrosoft.com”.

You can then check the Windows Event Log on the client machine and you will find a Event in System log with Source = Schannel and EventID 36882 complaining about Certificate received from the remote server was issued by an untrusted certificate authority.

6. Once the self-signed certificate has been added to your Computer’s Trusted Root Certificate Store, you will be able to

Hope this helps someone!