Find The Azure AD Join Type

KB ID 0001597

Problem

I recently did a post about Joining Azure AD. while working on that I found out there were three different Azure AD ‘States’ (see below). But how do you pingd out your Azure AD Join Type?

  • Azure AD Joined: Aimed at Corporate owned machines joined to Azure AD, (or CYOD devices).
  • Azure AD Registered (Was called Workplace Joined, and still is if you work in PowerShell). Aimed at BYOD devices.
  • Azure Hybrid AD Joined: Where your machines are joined to both your local domain and Azure AD.

Of course your Windows clients can also still be Domain Joined, or Simply Workgroup Joined. But you can’t be Domain Joined and Azure AD Joined. Thought to be even more confusingly you can be Domain Joined and Azure AD Registered.

How To Find The Azure AD Join Type

Azure AD Join Type: Azure AD Joined

The command you need to use is;

[box]

dsregcmd /status

[/box]

Look for AzureADJoined : YES. Also take a note of the DeviceId. (Note: Is should NOT say domain joined also, if it does, your join type is Hybrid!)

To check with PowerShell, first you need to connect with Connect-MsolService, then. log into Azure AD. Then you can query a DEviceId’s status with the following command.

[box]

Get-MsolDevice -DevideID {Device-ID-From Above}

[/box]

Look for DeviceTrustType: Azure AD Joined.

From within Azure > Azure Active Directory > Devices > Locate the Device in question > Join Type: Azure AD Joined.

Azure AD Join Type: Azure AD Registered (Workplace Joined)

When a device is AD registered then it has been connected from a logged on account, that has been connected, via the Access Work or School wizard. You can see this only if you’re logged on as that user! Settings > Accounts > Access work or School > Look for an enter under ‘Connect’.

If you are not logged on as the user then run there same command we ran above;

[box]

dsregcmd /status

[/box]

And look for a WorkplaceDeviceId.

Then use the same PowerShell commands as above. 

First you need to connect with Connect-MsolService, log into Azure AD. Then you can query a DEviceId’s status with the following command.

[box]

Get-MsolDevice -DevideID {Device-ID-From Above}

[/box]

Look for DeviceTrustType: Workplace Joined. (Yeah very consistent, thanks Microsoft ‘half a job’ developers!)

Azure AD Join Type: Azure Hybrid AD Joined

You can use the same command to view Azure AD Hybrid Domain Joined status.

[box]

dsregcmd /status

[/box]

If you are Azure Hybrid AD joined. you will see that AzureAdJoined :YES, and so is DomainJoined.

You can also look in Azure yourself, and the properties of the device will tell you you are Hybrid AD joined for this device.

Domain Joined

You can use the same command to view Local (On-Prem) Domain Joined status.

[box]

dsregcmd /status

[/box]

And look for DomainJoined : YES, and DomainName : {Your-Domain-Name}.

Of course as always you can see the information on your computer’s ‘Properties’, like so;

Note: An Azure AD Joined Machine does not show details here, in fact it says it’s workgroup joined! (Again thanks Microsoft, we’ve only looked here since Windows NT4, would it have been that much more work to update this as well?)

Related Articles, References, Credits, or External Links

NA

Windows: Join Azure AD (AAD)

KB ID 0001596

Problem

With more people looking at Microsoft 365 (as opposed to Office 365), then the amount of people who want to Join Azure AD with their Windows machines is only going to go up. This is how to join your Windows and BYOD client devices to Azure AD.

There are essentially 3 WAYS to Join Azure AD.

  • Azure AD Join: Used for corporate assets. Windows Only! (Can be managed by Intune) Users log in with their Azure AD account only.
  • Azure AD Registration: Used for BYOD devices Windows/macOS/Android etc. (Can be managed by Intune). Users log in with their local credentials.
  • Hybrid Azure AD Join: Used for corporate assets you want to manage with GPO (or SCCM). Windows Only. These assets will be in a local (traditional on-premises domain).-WARNING: These devices require periodic sight of your on-premises AD, (or they become unusable). The Local domain needs to be connected to Azure AD with an Azure AD Connector.

Solution

 

Join Azure AD: Azure AD Join

Start > Settings > Accounts..

Access Work or School > Connect.

STOP! If you put your credentials in here you will Not join the machine to Azure AD you will perform an Azure Workplace Join (or be Azure Registered) that’s NOT WAHT WE WANT > Select “Join This Device to Azure Active Directory‘.

Enter your Azure AD/Office 365 Credentials > Next.

Join.

Done.

The machine will now show that it’s connected to.Azure AD

Note: The login screen now changes to ‘Sign in to: Your Work or School account‘.

Join Azure AD: Azure AD Register

Start > Settings > Accounts..

Access Work or School > Connect.

Enter your O365/M365/Azure credentials

Then after authenticating you ‘should’ see this.

How To Leave / Disconnect From Azure AD

Same place as above, select the connection and simply click ‘Disconnect‘.

Join Azure AD: How To Hybrid Join Azure AD

To Hybrid Azure AD join your machines to Azure AD, (this means they will already be in you local (traditional on-premises) domain, and then ‘additionally’ joined to Azure AD also. So your local domain needs to be syncing to Azure AD with Azure AD Connect. And you machines need to be Windows 10 (or Windows 8 with some additional requirements!)

You configure Hybrid Azure AD Join on the Azure AD Connector, like so;

Locate Your Azure AD Connect Server

Launching Azure AD from the Azure AD connect icon, will pause replication and allow you to make changes, locate ‘Configure Device Options’

 

Next >authenticate to Azure > Next.

Device Options > Configure Hybrid Azure AD Join > Next.

Next > Select Windows 10 (unless you have Windows 8 then theres some other hoops you have to jump though for that though) > Next

Tick you local domain > Edit  >Authenticate to AD (with an Enterprise Admin account) > Next.

Exit.

Now, be patient and wait it can take a while for your devices to start appearing in Azure, when they do that will look like this;

Related Articles, References, Credits, or External Links

Find The Azure AD Join Type

Fortigate Load Balancing

KB ID 0001762

Problem

I’ve been getting through my NSE4, and one of todays topics was NAT, just as an offhand comment the ‘narrator‘ (I say narrator because it’s a monotonous robot AI voice,) mentioned Fortigate Load Balancing.

In the past (with my Cisco hat on) when I’ve been asked about load balancing, I’ve said ‘If you want to load balance, buy a load balancer‘. But the Fortigate does try to be ‘all things to all men‘ so I wondered just how good a load balancer can it be?

Turns out, quite a decent one, if you just want simple http round robin, it does that, it you want weighted traffic routing, or host health monitoring, or HTTP cookie persistence, and even SSL offload. It’s as good as anything I’ve ever worked on before. Here’s my Fortigate ‘Test Bench‘, you will see I’ve added three web servers (on the right) called Red, Green, and Blue (the significance of which will become apparent). Note: Yes there’s another web server at the bottom, (I’m too lazy to remove it from the lab!)

I’m going to setup simple round robin load balancing between these three web servers, and I’m going to get the Fortigate to monitor their health by simply making sure they respond to ping packets. (Note: it can monitor http availability or something a little better if you wish).

Solution

This tripped me up for a while! Load balancing is a feature, you need to  turn it on first, System > Feature Visibility > Load Balancing > Enable.

FortiGate Load Balancing: Create a Health Check

Cisco Types: Think of this as a tracked SLA

Policy & Objects > Health Check > Create New > Give it a name > Type = Ping > Interval = 10 > Timeout = 2 > Retry = 3 > OK

Now create a Virtual Server (not a VIP!) Policy  & Objects > Virtual Servers > Create New  > Name = Give it a sensible name > Type = HTTP > Interface = Your Outside/WAN interface  > Virtual Server IP (Externally!) > Virtual Server Port = 80 > Load Balancing method = Round Robin > Persistence = HTTP cookie > Heath Check = Select the one you created above.

Scroll down > Real Servers > Create New.

Add in the first (internal server IP) > Port = 80 > Max connections  = 0 (that’s unlimited) > OK.

Repeat the process to add the remaining servers > OK.

FortiGate Load Balancing: Enable Firewall Policy

Now you need to ‘allow’ traffic in (it is a firewall after all!) Policy & Objects > Firewall Policy (or IPv4 policy on older firewalls) > Create New > Name = Give it a sensible name > Incoming Interface = Outside > Outgoing Interface = Inside > STOP Change Inspection Mode to PROXY Based > Destination = Your Virtual Server (it’s not visible unless you have enabled proxy based!) > Schedule = Always > Service = All > Action = Accept > NAT = Enabled > You may also enable AV inspection > OK.

FortiGate Load Balancing:Testing and Tweaking

So from ‘Outside’ let’s hit our load balanced page.

That’s great but if you hit refresh a few times nothing changes (in production nothing would change anyway, but to prove my back end servers are getting used and load balanced, each of mine serves a different coloured page (hence the red, green and blue server names). The reason I’m only seeing the blue one, is because we enabled ‘HTTP cookie Persistence‘ let’s just nip back onto the firewall and disable that (set it to None > OK).

Now when I refresh by browser I can see it cycling though the back end servers.

FortiGate SSL Offload

To use and process SSL requires some CPU power, some websites (like this one) serve their webpages protected by https and the certificate that enables that lives on the web server, for sites like mine that are getting about 12k hits a day that’s fine but if you are getting hundreds of thousands of hits a minute that’s a MASSIVE drain on CPU resources. That’s what SSL offload is all about, getting another device (in this case the Fortigate) to do all the heavy lifting for you. Then the back end servers can get on with the job of serving web pages. 

Upload the Certificate to the FortiGate

For HTTPS you will need a web certificate that will be trusted by your visitors. I’m lazy and tight so I’ll just create one in Microsoft Certificate Services, but in Production you will need Publicly Signed Certificate. System > Certificates (if you can’t see certificates) > Import > Local Certificate.

Mine’s in PFX format so I need to select PKCS#12 > upload the certificate and supply a password > OK

FortiGate: Enable SSL Offload

On your Virtual Server, change the Type to HTTPS > Virtual ServerPort to 443 > Certificate to the one you just uploaded > OK.

We are now serving pages securely even though the web servers are not configured for https.

Related Articles, References, Credits, or External Links

NA