Deep-dive to Azure AD machine be part of

Units (endpoints) are an important a part of Microsoft’s Zero Belief idea. Units might be Registered, Joined, or Hybrid Joined to Azure AD.
Conditional Entry makes use of the machine info as one of many selections standards to permit or block entry to providers.

On this weblog, I’ll clarify what these completely different registration varieties are, what occurs under-the-hood in the course of the registration, and find out how to register units with AADInternals v0.4.6.

Technically, a tool is without doubt one of the object varieties in Azure AD. The machine object is typically referred to as machine identification.

The place customers are recognized based mostly on their credentials, units are recognized by certificates. In different phrases, a tool certificates represents the machine registered to Azure AD.
These certificates are created in the course of the registration course of (this can be defined later).

There are three completely different registration varieties, that are referred to as Be a part of Sorts. In keeping with documentation
these varieties are:

Subsequent, let’s view the documentation to see intimately the variations between these be part of varieties!

Azure AD Registered

In keeping with documentation:

The purpose of Azure AD registered units is to offer your customers with assist for the Deliver Your Personal Machine (BYOD) or cell machine situations. In these situations, a consumer can entry your group’s Azure Lively Listing managed assets utilizing a private machine.

Azure AD Joined

In keeping with documentation:

Azure AD be part of is meant for organizations that wish to be cloud-first or cloud-only. Any group can deploy Azure AD joined units regardless of the dimensions or business. Azure AD be part of works even in a hybrid surroundings, enabling entry to each cloud and on-premises apps and assets.

Azure AD Hybrid Joined

In keeping with documentation:

Usually, organizations with an on-premises footprint depend on imaging strategies to provision units, and so they typically use Configuration Supervisor or group coverage (GP) to handle them.

In case your surroundings has an on-premises AD footprint and also you additionally need profit from the capabilities supplied by Azure Lively Listing, you may implement hybrid Azure AD joined units. These units, are units which are joined to your on-premises Lively Listing and registered together with your Azure Lively Listing.

Now that we all know the aim of various be part of varieties let’s dive into technical particulars!

Machine Object

Machine objects are saved to Azure AD. Primarily based on my analysis, listed below are the related attributes and their values associated to completely different be part of varieties.

Be aware! The attribute names offered listed below are these uncovered by Azure Lively Listing Graph API with
api-version=1.61-internal question parameter.

objectId

The id of the Azure AD machine object.

deviceId

The machine id attribute of the Azure AD machine object. For Hybrid Joined units, equals to equals to objectGuid of the on-prem AD machine object.

deviceTrustType

Signifies the be part of sort.

dirSyncEnabled

Signifies whether or not the machine is synchronised from the on-prem AD or not. True for Hybrid Joined units.

isManaged

Signifies whether or not the machine is managed or not. All the time True for Hybrid Joined units. For Registered and Joined units, the attribute must be set by machine administration utility
or AADInternals Set‑AADIntDeviceCompliant operate.

isCompliant

Signifies whether or not the machine is compliant or not. Attribute must be set by machine administration utility
or AADInternals Set‑AADIntDeviceCompliant operate.

reserved1

The userCertificate attribute of the machine from the on-prem AD object for Hybrid Joined units. Public key with a topic title that equals to objectGuid of the on-prem AD machine object.

onPremisesSecurityIdentifier

The safety identifier (SID) of the on-prem AD machine object. Solely set for Hybrid Joined units.

profileType

All the time RegisteredDevice for Registered and Joined units. For Hybrid Joined units initially empty after synced from on-prem AD, set to registered after the precise be part of.

deviceSystemMetadata

Metadata in regards to the machine registration.

Be a part of course of

Now that we all know the three completely different be part of varieties let’s dive to course of how every of those be part of varieties are carried out.

Units with completely different Be a part of Sort as seen in Azure AD portal:

Register

Registering units to Azure AD has 5 steps:

1. Generate Machine key and Transport key.

   The registration software program (relies on the machine) generates two keysets referred to as Machine key (dkpub/dkpriv) and Transport key (tkpub/tkpriv). The non-public keys are saved within the machine.

   The Machine key is used to establish the machine, whereas the Transport key is used to decrypt the session key when requesting the PRT (see this weblog for particulars).

   A certificates signing request (SCR) for “CN=7E980AD9-B86D-4306-9425-9AC066FB014A” (dkpub) is generated with dkpriv.

2. Request entry token for Azure AD Be a part of

   The registration software program request entry token for appid 1b730954-1685-4b74-9bfd-dac224a7b894 with 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 viewers.

3. Return entry token

4. Enroll machine

   A http POST request is made to “https[:]//enterpriseregistration.home windows.internet/EnrollmentServer/machine/?api-version=1.0” to register the machine to Azure AD:

    1{
    2    "TransportKey":  "UlNBMQAIAAADA[redacted]+Ht0sYG4vPqK1B2wQcnkO4cZhJ2Q==",
    3    "JoinType":  4,
    4    "DeviceDisplayName":  "Registered Machine",
    5    "OSVersion":  "C64",
    6    "CertificateRequest":  {
    7                               "Sort":  "pkcs10",
    8                               "Knowledge":  "MIICdDCCAVwCAQAwLzE[redacted]n/rOiQamubMpzL1eaEhWLH8v9hkxZic="
    9                           },
   10    "TargetDomain":  "contoso.com",
   11    "DeviceType":  "Commodore",
   12    "Attributes":  {
   13                       "ReuseDevice":  true,
   14                       "ReturnClientSid":  true,
   15                       "SharedDevice":  false
   16                   }
   17}

   The dkpub (row 8) and tkpriv (row 2) are Base64 encoded. The be part of sort (row 3) signifies machine registration.

5. Return machine certificates

   The return worth accommodates the signed (dkpub) of the Machine key (row 4) and its thumbprint (row 3). The proprietor of the machine can be returned (row 7).

    1{
    2    "Certificates": {
    3        "Thumbprint": "EA9CE04D0FCFB4AB382E253B7F1BC48CBC60010B",
    4        "RawBody": "MIID8jCC[redacted]IE34ylUixWmNVJj39HQ5ky4+0cY6JR1JovPLaCQ"
    5    },
    6    "Person": {
    7        "Upn": "[email protected]"
    8    },
    9    "MembershipChanges": [{
   10            "LocalSID": "S-1-5-32-544",
   11            "AddSIDs": ["S-1-12-1-4209995732-1115842628-132208791-3473393508", "S-1-12-1-1284395347-1172857899-2838897599-3439875365"]
   12        }
   13    ]
   14}

Be a part of

The method becoming a member of units to Azure AD is equivalent to registering units:

1. Generate Machine key and Transport key.
2. Request entry token for Azure AD Be a part of
3. Return entry token
4. Enroll machine

   Solely distinction to the Registration is the JoinType (row 3):

    1{
    2    "TransportKey":  "UlNBMQAIAA[redacted]QkSnl0b8xkWqv5CKfBp8RQ==",
    3    "JoinType":  0,
    4    "DeviceDisplayName":  "Joined Machine",
    5    "OSVersion":  "Vic20",
    6    "CertificateRequest":  {
    7                               "Sort":  "pkcs10",
    8                               "Knowledge":  "MIICdDCCAVwCAQAwLz[redacted]2003EixNAH3U7ggIXgXBWwtVbs="
    9                           },
   10    "TargetDomain":  "contoso.com",
   11    "DeviceType":  "Commodore",
   12    "Attributes":  {
   13                       "ReuseDevice":  true,
   14                       "ReturnClientSid":  true,
   15                       "SharedDevice":  false
   16                   }
   17}

5. Return machine certificates

Hybrid Be a part of

As talked about earlier, hybrid joined units are joined to each on-prem AD and Azure AD. Hybrid Becoming a member of is just like Registering and Becoming a member of, however there are some massive variations.

First, the machine object has to exist in Azure AD earlier than the be part of might be carried out. There are two methods to create the hybrid machine object to Azure AD: it may be synced from on-prem AD
with Azure AD Join, or it may be generated by way of identification federation. With the latter method, the machine object is created instantly to Azure AD, whereas the previous technique creates the item in the course of the subsequent synchronisation cycle.

Second, the machine is joined by the system, not the consumer. The authentication technique used in the course of the becoming a member of relies on how the machine object is created to Azure AD:

• For the Azure AD Join synchronisation, the authentication is carried out by signing part of the enrollment request with the non-public key of the pc’s machine certificates.
  Azure AD can confirm the pc’s identification by validating the signature with the general public key of the machine certificates. The general public secret’s saved in Azure AD within the reserved1 attribute of the machine object.

• For the identification federation, the authentication is carried out by requesting a SAML token from AD FS and requesting an entry token from Azure AD with that SAML token. The ensuing entry token is then used for the enrollment request.

Let’s begin with the Azure AD Join synchronisation movement:

1. Generate Machine certificates
2. Set the worth of userCertificate attribute of the machine’s on-prem AD object to match the general public key of the Machine certificates.
3. Synchronise the machine object to Azure AD.
   The Machine Id attribute of the machine’s Azure AD object is about to ObjectGuid of the machine’s on-prem AD object.
4. Generate Machine key and Transport key.
5. Enroll machine

   The http POST request is a bit completely different than with Register and Be a part of:

    1{
    2    "ServerAdJoinData":  {
    3                             "DeviceType":  "Home windows",
    4                             "TransportKey":  "UlNBMQAIAAA[redacted]eXG2wVZ/D6/VtQZCgxrq0uOEdGvJ+Gwwez6GQ==",
    5                             "TargetDomainId":  "5694aa9c-04e1-4df1-9d37-5d64d0915d42",
    6                             "OSVersion":  "Vista",
    7                             "TargetDomain":  "",
    8                             "ClientIdentity":  {
    9                                                    "Sid":  "S-1-5-21-181028512-47807049-227815571-9284.2021-02-20 08:57:42Z",
   10                                                    "Sort":  "sha256signed",
   11                                                    "SignedBlob":  "mt4lVuVcnAsc[redacted]pYAr+d8LJZyfNan6MeXvk+2SU40BGkfdw=="
   12                                                },
   13                             "SourceDomainController":  "dc.contoso.com",
   14                             "DeviceDisplayName":  "Hybrid Joined Machine 2"
   15                         },
   16    "CertificateRequest":  {
   17                               "Sort":  "pkcs10",
   18                               "Knowledge":  "MIICdDCCAVwCAQAwL[redacted]ctccQcPO0wwtq0dKUk/+V8aKw4i4TNznHeZ3DY="
   19                           },
   20    "Attributes":  {
   21                       "ReuseDevice":  true,
   22                       "ReturnClientSid":  true,
   23                       "SharedDevice":  false
   24                   },
   25    "JoinType":  6
   26}

   The be part of sort (row 25) signifies Hybrid Be a part of. Additionally, the SID of the machine is distributed (row 9), and it should match the onPremisesSecurityIdentifier of the machine’s Azure AD object.

   The enrollment request is authorised by calculating a SHA256 hash from “<SID>.<timestamp>” (row 9) and signing the hash with the non-public key of the Machine certificates. The signature (row 11) is distributed with the enrollment request.

6. Return machine certificates

Identification federation movement:

1. Generate Machine certificates
2. Set the general public key of the Machine certificates to the userCertificate attribute of the machine’s on-prem AD object.
3. Request SAML token.
   The pc requests a SAML token from the AD FS server.
4. Return SAML token.

   The token contains the title (row 15) and SID (row 27) of the machine and its on-prem AD GUID in Base64 encoded format (rows 9,18, 24, and 35). The account sort is all the time DJ (row 21).

    1<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_b2db43d0-2f96-479e-a31f-e8225326fdbb" Issuer="http://e5.myo365.web site/adfs/providers/belief/" IssueInstant="2021-02-21T15:13:15.505Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
    2	<saml:Situations NotBefore="2021-02-21T15:13:15.505Z" NotOnOrAfter="2021-02-21T16:13:15.505Z">
    3		<saml:AudienceRestrictionCondition>
    4			<saml:Viewers>urn:federation:MicrosoftOnline</saml:Viewers>
    5		</saml:AudienceRestrictionCondition>
    6	</saml:Situations>
    7	<saml:AttributeStatement>
    8		<saml:Topic>
    9			<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">UUEMXKriXkOYeql655jERA==</saml:NameIdentifier>
   10			<saml:SubjectConfirmation>
   11				<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>
   12			</saml:SubjectConfirmation>
   13		</saml:Topic>
   14		<saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims">
   15			<saml:AttributeValue>[email protected]</saml:AttributeValue>
   16		</saml:Attribute>
   17		<saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05">
   18			<saml:AttributeValue>UUEMXKriXkOYeql655jERA==</saml:AttributeValue>
   19		</saml:Attribute>
   20		<saml:Attribute AttributeName="accounttype" AttributeNamespace="http://schemas.microsoft.com/ws/2012/01">
   21			<saml:AttributeValue>DJ</saml:AttributeValue>
   22		</saml:Attribute>
   23		<saml:Attribute AttributeName="onpremobjectguid" AttributeNamespace="http://schemas.microsoft.com/identification/claims">
   24			<saml:AttributeValue>UUEMXKriXkOYeql655jERA==</saml:AttributeValue>
   25		</saml:Attribute>
   26		<saml:Attribute AttributeName="primarysid" AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identification/claims">
   27			<saml:AttributeValue>S-1-5-21-126850608-2097551590-1142751551-1260</saml:AttributeValue>
   28		</saml:Attribute>
   29		<saml:Attribute AttributeName="insidecorporatenetwork" AttributeNamespace="http://schemas.microsoft.com/ws/2012/01" a:OriginalIssuer="CLIENT CONTEXT" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identification/claims">
   30			<saml:AttributeValue>true</saml:AttributeValue>
   31		</saml:Attribute>
   32	</saml:AttributeStatement>
   33	<saml:AuthenticationStatement AuthenticationMethod="urn:federation:authentication:home windows" AuthenticationInstant="2021-02-21T15:13:15.505Z">
   34		<saml:Topic>
   35			<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">UUEMXKriXkOYeql655jERA==</saml:NameIdentifier>
   36			<saml:SubjectConfirmation>
   37				<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>
   38			</saml:SubjectConfirmation>
   39		</saml:Topic>
   40		<saml:SubjectLocality IPAddress="" DNSAddress=""/>
   41	</saml:AuthenticationStatement>
   42	<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
   43		<SignedInfo>
   44			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   45			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
   46			<Reference URI="#_b2db43d0-2f96-479e-a31f-e8225326fdbb">
   47				<Transforms>
   48					<Remodel Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
   49					<Remodel Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   50				</Transforms>
   51				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
   52				<DigestValue>tLyWWYmqHM5OqQoULGhxtO0iFiHu2uqg/nmS0orxfG4=</DigestValue>
   53			</Reference>
   54		</SignedInfo>
   55		<SignatureValue>Ook5qUQYD[redacted]/39yd2WVc3ZbN5asVD6a3kU25ZqCY3A==</SignatureValue>
   56		<KeyInfo>
   57			<X509Data>
   58				<X509Certificate>MIIC7jCCA[redacted]SV4JYS3wGstXeMw5qx++5fw==</X509Certificate>
   59			</X509Data>
   60		</KeyInfo>
   61	</Signature>
   62</saml:Assertion>

5. Request entry token for Azure AD Be a part of
   Requests an entry token utilizing the SAML token.
6. Return entry token
   The returned entry token appears to be like like a standard consumer token, however there are some variations.

   The token accommodates account sort (row 7), which is all the time “DJ”. It additionally accommodates the on-prem AD object id (row 16) and SID (row 17) of the machine.

   The idp (row 13) and unique_name (row 23) attributes accommodates what appears to be the issuer uri of the AD FS. Nonetheless, this isn’t the case, because the area a part of the uri is the area of the machine, not FQDN of the AD FS service.

    1{
    2    "aud": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
    3    "iss": "https://sts.home windows.internet/8c63b77b-19de-4b04-a8b2-ae8bb19a00fe/",
    4    "iat": 1613920183,
    5    "nbf": 1613920183,
    6    "exp": 1613924083,
    7    "account_type": "DJ",
    8    "acr": "1",
    9    "aio": "AXQAi/8TAAAASTiNcttgcax[redacted]o27/TRsgA==",
   10    "amr": ["wia"],
   11    "appid": "1b730954-1685-4b74-9bfd-dac224a7b894",
   12    "appidacr": "0",
   13    "idp": "http://firm.com/adfs/providers/belief/",
   14    "in_corp": "true",
   15    "ipaddr": "13.122.32.15",
   16    "on_prem_id": "5c0c4151-e2aa-435e-987a-a97ae798c444",
   17    "primary_sid": "S-1-5-21-1768792239-781667213-1105014165-9071",
   18    "rh": "0.AAAAnKqUVuEE8U2dN11k0JFdQlQJcxuFFnRLm_3awiSnuJR5AIE.",
   19    "scp": "policy_management",
   20    "sub": "6vWJbn3QWCXJShfSB3c2MbRKe5YPYZ01e3nLFlWiUFk",
   21    "tenant_region_scope": "EU",
   22    "tid": "8c63b77b-19de-4b04-a8b2-ae8bb19a00fe",
   23    "unique_name": "http://firm.com/adfs/providers/belief/#",
   24    "uti": "fjp57QEVuEGDuKTRzjQkAA",
   25    "ver": "1.0",
   26    "xms_sptype": "0"
   27}

7. Generate Machine key and Transport key.
8. Enroll machine
9. Return machine certificates

Units are an important a part of Microsoft’s Zero Belief idea:

In observe, implementing Zero Belief requires Azure AD Conditional Entry (CA), which is included in Azure AD Premium P1. Amongst different issues, with CA, we will enable or deny entry based mostly on the machine info.

In keeping with documentation,
we will require the machine to be managed. Managed units are units which are both Hybrid Joined or marked as compliant.

The Hybrid Joined units are assumed to be managed by Configuration Supervisor and/or GPOs.
Different units might be marked compliant by Cell Machine Administration (MDM) system, reminiscent of Intune. Nonetheless, as I described in an earlier weblog put up, the machine compliance might be “faked”, relying on the compliance necessities.
The compliance may also be set by AADInternals Set‑AADIntDeviceCompliant operate.

As talked about earlier, units registered or joined to Azure AD permits single-sign-on (SSO) for Azure AD. The SSO is applied by Main Refresh Tokens (PRTs),
which might be created with the machine and transport certificates.
The method and particulars of making PRTs are described in an earlier weblog put up.

One vital element associated to PRTs is the authentication technique used when the machine was registered or joined to Azure AD. If the consumer was authenticated with MFA, additionally the entry tokens fetched utilizing the PRT can have
the MFA declare set. This may fulfill MFA requirement of CA insurance policies. Directors can change the strategies after the registration with AADInternals Set‑AADIntDeviceRegAuthMethods operate.

AADInternals can register, be part of, and hybrid be part of units to Azure AD with Be a part of‑AADIntDeviceToAzureAD operate.
Let’s see how to do that in motion!

Registering units

Registering units to Azure AD is supported in AADInternals model v0.4.6 and later.

To register a tool, receive an entry token and supply Register as JoinType:

# Get entry token for Azure AD Be a part of and save to cache
Get-AADIntAccessTokenForAADJoin -SaveToCache

# Register a brand new machine to Azure AD
Be a part of-AADIntDeviceToAzureAD -DeviceName "My Registered Machine" -JoinType Register

Output:

Machine efficiently registered to Azure AD:
  DisplayName:     "My Registered Machine"
  DeviceId:        77b7781f-9531-44f0-bae2-ad45b995880a
  Cert thumbprint: 00D8F218928A63D466091BA6847CE5A701A75218
  Cert file title : "77b7781f-9531-44f0-bae2-ad45b995880a.pfx"
Native SID:
  S-1-5-32-544
Extra SIDs:
  S-1-12-1-4209995732-1115842628-132208791-3473393508
  S-1-12-1-1284395347-1172857899-2838897599-3439875365

Becoming a member of units

The JoinType defaults to Be a part of, so becoming a member of a tool is straightforward:

# Get entry token for Azure AD Be a part of and save to cache
Get-AADIntAccessTokenForAADJoin -SaveToCache

# Register a brand new machine to Azure AD
Be a part of-AADIntDeviceToAzureAD -DeviceName "My Joined Machine"

Output:

Machine efficiently registered to Azure AD:
  DisplayName:     "My Joined Machine"
  DeviceId:        bbe84457-2c93-4857-a7e4-0573fdcfd229
  Cert thumbprint: 6AFA62FEF611EBC1DFDA72B0221C986B77CF7597
  Cert file title : "bbe84457-2c93-4857-a7e4-0573fdcfd229.pfx"
Native SID:
  S-1-5-32-544
Extra SIDs:
  S-1-12-1-4209995732-1115842628-132208791-3473393508
  S-1-12-1-1284395347-1172857899-2838897599-3439875365
  S-1-12-1-1372034668-1267036473-87356082-2200290463

Hybrid becoming a member of units

As defined earlier, hybrid be part of requires {that a} machine object exists in Azure AD. Furthermore, we now know that there are two methods to create these machine objects to Azure AD.

Hybrid becoming a member of to synced machine – choice 1

Let’s begin by creating a tool object to on-prem AD, syncing it to Azure AD, and hybrid becoming a member of it.

The next script creates a pc object to on-prem AD (rows 1-5), will get its GUID (rows 6-7), creates a self-signed certificates for it utilizing AADInternals (row 8), and at last, units the general public key
of the certificates to the userCertificate attribute of the pc object (row 9).

1$ComputerName = "DESKTOP-1234"
2$ComputerOU =   "OU=Computer systems,DC=firm,DC=com"
3$CloudDomain =  "firm.com"
4
5New-ADComputer -Identify $ComputerName -SAMAccountName $ComputerName -DisplayName $ComputerName -Path $ComputerOU -Enabled $true
6$ComputerObject = Get-ADComputer $ComputerName 
7$ComputerGuid = $ComputerObject.ObjectGUID
8New-AADIntCertificate -SubjectName "CN=$ComputerGuid" -Export
9Set-ADObject $ComputerGuid -Add @{"userCertificate" = [byte[]](get-content ".CN=$ComputerGuid.cer" -Encoding byte)}

Because the output reveals, the generated certificates can be exported to a file:

Certificates efficiently exported:
  CN=09d302c1-8160-430a-a9b1-a699ae696b31.pfx
  CN=09d302c1-8160-430a-a9b1-a699ae696b31.cer

The script created a brand new laptop object to the Lively Listing:

Subsequent, run the next cmdlet to start out the sync:

After the sync, the machine seems in Azure AD:

Now we will proceed the script we began earlier. First, we have to get the tenant id (row 10).
By utilizing the generated certificates and offering the title and SID of the pc, we will hybrid be part of the machine (row 11):

10$TenantId = Get-AADIntTenantID -Area $CloudDomain
11Be a part of-AADIntDeviceToAzureAD -PfxFileName ".CN=$ComputerGuid.pfx" -DeviceName $ComputerObject.Identify -SID $ComputerObject.SID -TenantId $TenantId

Machine efficiently registered to Azure AD:
  DisplayName:     "DESKTOP-1234"
  DeviceId:        09d302c1-8160-430a-a9b1-a699ae696b31
  Cert thumbprint: 99EE3264242568BDDB3D0800C064F9D369B051E8
  Cert file title : "09d302c1-8160-430a-a9b1-a699ae696b31.pfx"

Now the pc is efficiently hybrid joined to Azure AD:

Hybrid becoming a member of to synced machine – choice 2

Additionally it is potential to create machine objects on to Azure AD with AADInternals utilizing Be a part of‑AADIntOnPremDeviceToAzureAD operate.
The operate makes use of the identical API Azure AD Join is utilizing, so International Admin or Listing Synchronization Accounts function is required.

If SID, DeviceId, or certificates will not be supplied, the operate will generate them.

# Get entry token and save to cache
Get-AADIntAccessTokenForAADGraph -SaveToCache 

# Create a tool object to Azure AD
Be a part of-AADIntOnPremDeviceToAzureAD -DeviceName "DESKTOP-5678"

Machine efficiently created:
  Machine Identify:     "DESKTOP-5678"
  Machine ID:       663cb1d1-bd4b-412f-a673-14f04ea55622
  Machine SID:      S-1-5-21-378725881-735212363-822861820-5928
  Cloud Anchor:    Device_d7bf50e4-9538-43e9-b1ed-d20f8fd60064
  Supply Anchor:   0bE8Zku9L0GmcxTwTqVWIg==
  Cert thumbprint: DF40352AD440EF8A4BECC27347A4FA9D35677188
  Cert file title:  "663cb1d1-bd4b-412f-a673-14f04ea55622-user.pfx"

We will now use the generated certificates and different info to hybrid be part of the machine:

# Get the tenant id
$TenantId = Get-AADIntTenantID -Area firm.com
# Hybrid be part of the machine
Be a part of-AADIntDeviceToAzureAD -DeviceName "DESKTOP-5678" -SID "S-1-5-21-378725881-735212363-822861820-5928" -TenantId $TenantId -PfxFileName .663cb1d1-bd4b-412f-a673-14f04ea55622-user.pfx

Machine efficiently registered to Azure AD:
  DisplayName:     "DESKTOP-5678"
  DeviceId:        663cb1d1-bd4b-412f-a673-14f04ea55622
  Cert thumbprint: BCDFF1388B845A2CEF4D0C9F4C08DD68CC130B41
  Cert file title : "663cb1d1-bd4b-412f-a673-14f04ea55622.pfx"

Hybrid becoming a member of by federation

To hybrid be part of a tool with federation, a SAML token is required. To create the SAML token, we have to have the token signing certificates and the issuer uri of the identification supplier.

Be aware: AD FS certificates export performance was closely refactored in v0.4.7. See the weblog for particulars.

Easies option to get the certificates is to export it from AD FS with AADInternals:

# Export AD FS token signing and encryption certificates
Export-AADIntADFSCertificates

To get the issuer uri, run the next cmdlet on AD FS server:

# Get AD FS issuer uri
$issuer = (Get-AdfsProperties).Identifier.OriginalString

To create a SAML token for the machine:

# Create a brand new SAML token
$saml = New-AADIntSAMLToken -UserName "DESKTOP-9999" -DeviceGUID (New-Guid) -Issuer $issuer -PfxFileName .ADFS_signing.pfx

Now now we have all we have to hybrid be part of the machine:

# Get an entry token for the machine with the SAML token
Get-AADIntAccessTokenForAADJoin -SAMLToken $saml -Machine -SaveToCache

# Hybrid be part of the machine
Be a part of-AADIntDeviceToAzureAD -DeviceName "DESKTOP-9999"

Machine efficiently registered to Azure AD:
  DisplayName:     "DESKTOP-9999"
  DeviceId:        0810056c-d2d5-4c1b-bc17-2f2fbedd6ca3
  Cert thumbprint: 3022FF7937C0766CE3DB0AD45C9413FB68A05EE3
  Cert file title : "0810056c-d2d5-4c1b-bc17-2f2fbedd6ca3.pfx"
Native SID:
  S-1-5-32-544
Extra SIDs:
  S-1-12-1-3240472016-1160587922-3614255014-3410032901
  S-1-12-1-2566832563-1141717763-392342924-578657198

On this weblog put up, I defined what occurs under-the-hood when units are joined to Azure AD. Though there are three completely different be part of varieties, all machine certificates are technically equivalent.

Subsequent query could be find out how to exploit what we’ve have discovered? Nicely, that’s one other story quickly to be advised 😉