NPS Extension for MFA – All you need to know

NPS extension for MFA helps to make use of Azure MFA for on VPN connectivity.  Although the documentation from Microsoft is straight forward to explain how that work and how to configure, we don’t have much information online.

Let’s assume that you have a Radius server as

  1. Lab-DCRadius.
  2. Cisco-Asa

console1

 

  • I have configured Cisoco-ASA to use lab-DCRadius. On NPS server, I have configured CiscoASA as Radius client to access connection
  • Test the VPN using Cisco AnyConnect to LabVPN.Lab.com

From the following diagram, illustrate the flow.  (The above said registry keys play the role of transferring the secondary Auth to Azure MFA)

flow

Once you confirm that VPN is working,

Install the NPS extension from here, there are 2 version 1.0.1.16 & 1.0.1.20 (1.0.1.21 is available but on request to Microsoft)

To make sure Azure MFA accept the request from the NPS server,

Once you install it you have to run the script that comes with the NPS extension

  • Run Windows PowerShell as an administrator.
  • Change directories.
  • cd “C:\Program Files\Microsoft\AzureMfa\Config”
  • Run the PowerShell script created by the installer.

.\AzureMfaNpsExtnConfigSetup.ps1

  • Sign in to Azure AD as an administrator.
  • PowerShell prompts for your tenant ID. Use the Directory ID GUID that you copied from the Azure portal in the prerequisites section.
  • PowerShell shows a success message when the script is finished.

 

What this does is it

  1. Sets the registry with a some values
  2. Creates a self-signed certificate on your server and uploade the certificate on Azure.

To verify check the following registry key

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa

tempsnip

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\

reg

To verify the certificate,

Local Certificate

  1. Open MMC -> File- > Add/Remove Snap-in-> Certificate -> Local Computer, Click Ok
  2. Navigate to Certificates -> Personal – >Certificates

You will find a certificate with the tenant Id.

  1. Go to the properties of the certificate, under details tab, look for Thumbprint, Copy it somewhere.
  2. Now open Azure module for Windows PowerShell
  3. Run the command in the screenshot

msol

  1. Copy the value in to a notepad and save it as .cer (if you have more than one cert, you might see more values. You have to copy each one of them in to a separate file and save it as .cer)
  2. Now open the save .cer file.
  3. Now under details tab, look for Thumbprint property.

Computer these 2 thumbprint and make sure they matches.

Gotchas

  1. What if registration fails – This usually happens either if your AD account doesn’t have access to local certificate store or Azure portal (GA admin is the requirement to upload the cert)
  2. How do I disable MFA on one of the NPS server to test it?
  • You can disable the MFA on NPS server.  This is essential to find out when you are troubleshooting to narrow down which NPS server is having the issue. To disable the MFA on a NPS server without de-registering it,
  • Navigate to the registry key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Serevice\AuthSrv\Parameters, Empty the following key values
    • AuthorizationDLLs
    • ExtentionDLL
  • This will stop the NPS to look for Secondary Auth
  1. How to renew the certificate when it expires
  • The certificate usually has 2 years of validity.  You can renew it by simply running AzureMfaNpsExtnConfigSetup.PS1

Known issue.

Recently, I have seen the ver. 1.0.1.20 is causing performance issue.  There is a newer version which fixes the problem 1.0.1.21.

Exclaimer for Office 365 – Update

Most of my customer use Exclaimer.  Eversince Office 365 started rolling out, Excliamer started Cloud signature to support Office365 customers.

If you have used on-prem Exclaimer signature manager (Exchange Edition) in the past, you must have come across Policy Tester which used to be very handy in troubleshooting.

policytester

This policy tester was missing in the Exclaimer Cloud.  This made troubleshooting really difficult,

But Exclaimer seem to have taken the feedback and brought this feature to the cloud as well.  It is called “Signature Rules Tester”

CloudExclaimer

https://cloudsupport.exclaimer.com/hc/en-us/articles/360008007993-What-is-the-Signature-Rules-Tester-

VJ

 

Cannot add new connectors – AADConnect

AAD Connect is very flexible when the organization expands but at the sametime we should make sure the AAD Connect is up-to-date to coupe with the changes.

One of the incident that I’ve encounter may help others.

Issue : Cannot add new connectors to AAD Connect

I wanted to add a new forest to sync up to the Azure AD. All these users are going to be in the same office 365 Tenant.

Symptoms:

When i add the connector (Microsoft way – Using AAD Connect wizard), I get the following error

E_MMS_SCHEMA_CLASS_NOT_FOUND

When i check the logs,

schema

Troubleshooting:

  • Ports
    • Checked the ports to see if the domain is reachable
    • Made sure the domain name is resolved to the right ip’s
  • The schema made be feel that, the service account doesn’t have rights on the forest that is being added
    • Checked the permisisons –  it is all good
    • Changed the permission to Domain admin
  • Adding new connector
    • Added a new connector manually (click the new connector from Synchronization service console)
    • Pointed to the forest
    • When i did the right-click and “Search Connector space”, i can see all the objects from the domain (it wont sync anyway as the sync rule wont get populated, if you use “Create” connector)

At this point, i understood that it is not a problem with the forest that i’m trying to add.

I ran the wizard without adding the connector, i got the same error.  So this proves that there is an issue with the existing connector.

Resolution:

I ran refresh schema on all the existing connector.  I found one of the connector had a schema changes which wasn’t picked up by the AAD Connect (One of the forest administrator installed Exchange server in their infrastructure)

tempsnip

After refreshing the schema, i ran the wizard, it went like a charm.

 

 

Password hash sync is not working for sub-domains – AAD Connect

Issue: The password sync for sub-domains are not working

Data Collected:

  1. The password hash sync for the root domain and selective sub-domains are working without any problem
  2. The user and other objects from the selected OU of the all the root domain and the sub-domain works without any issues
  3. There is no sync errors for the object which doesn’t sync the password
  4. When a password has been reset for the object from the sub-domain, there is no event id 656 or 657 logged on the AAD Connect server
  5. Properties of the connectors shows that sub-domain Directory partition has been checked.

Troubleshooting:

Before I proceed, I have done everything mentioned in the article below,

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-troubleshoot-password-hash-synchronization

  1. Checked whether password hash is enabled – It is
  2. When I run the following command,

Invoke-ADSyncDiagnostics –PasswordSync

From the following screenshot it shows that the sub-domains directory partition not considered as domain.

1

  1. Ran the above command against the object in the sub-domain for which the password sync is not working

Invoke-ADSyncDiagnostics -PasswordSync -ADConnectorName <Name-of-AD-Connector> -DistinguishedName <DistinguishedName-of-AD-object>

2

If you look closely, it says that it is available in metaverse database but an error for the objects of the sub-domain

“There is no password has synchronization rule for AD Connector space object”

  1. But that’s not right as you can see from below screenshot, There is a sync rule for “In from AD – User AccountEnabled” is true

3

 I didn’t bother to get deep in to the sync rule as the installation not customized.  I was sure that the domain partition is not recognized

  1. The domain partitions are selected in the connector properties.

To check this,

  • Right click on the connector
  • Choose properties
  • From the popup window, click on “Configure Directory Partitions”

I now came to conclusion that the domain partition is not recognised but from the GUI it shows it is selected.

After some googling, I found 3 interesting cmdlets

  • Enable-ADSyncConnectorPartition
  • Enable-ADSyncConnectorPartitionHierarchy
  • Update-ADSyncConnectorPartition

There is no explanation of these cmdlets but I did manage to run it but with no success.

Resolution:

So finally I’ve gone back to basics of powershell.

Get-ADSyncConnector

4

This gives me list of connectors.  I need the first connector (where the sub-domain is)

$c = Get-ADSyncConnecor

I’m interested in the first connector and its partition, I’m assign that into the variable

$adConn= $c[0]

$AdConn.Partitions

This will list down the list of partitions under that connector.  There are about 5 partition, out of that last 2 partition’s object is having problems

5

If you closely look in the attribute called “IsDomain” is set to “False”, but the same is “True” for the rest of the domain partition (Its not in the screenshot though)

This exactly the same reason when we ran the password sync troubleshooter, it said that the sub-domain in questions is not a domain

To change this value, run the following command, for 2 sub-domains

$adConn.Partitions[5].IsDomain=$true

$adConn.Partitions[6].IsDomain=$true

After the change it will look like below

6

We are not done yet.  This should take care of the password sync but

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector “domain.net” –TargetConnector “domain.onmicrosoft.com – AAD” -Enable $false

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector “domain.net” –TargetConnector “domain.onmicrosoft.com – AAD” -Enable $True

Soon after this, the eventlog shows lot of 656 events indicating that password sync of the objects from sub-domains are syncing.

 VJ

 

Unable to login to Office 365 Tenant

I’ve encountered an interesting issue that may be well useful to troubleshoot and how to fix it

Issue : Users are unable to login to http://portal.office.com.  They get the following error

Login-Error

Analysis :

The error message itself is not very useful.  So, i had to collect few information to know what is going on

  1. AAD Connect for that tenant is still running.  There is a recent delta sync success in the logs
  2. Everyone including the Global administrator cannot login
  3. Checked with other tenants, and there is no news from MS on the message center (this rules out if this is a Microsoft issue)
  4. Password change seems to be replication.  There are logs for the users who recently changed their password
  5. The AAD connect version is 1.1.5

The information collected was not so very useful at all except one thing

Full/Delta Synchronization is working without any issue

Troubleshooting:

Ran Fiddler from the machine  where i tried logging to office 365 and found an interesting information.

Fiddlerlog

If you closely look at it, the authentication is being redirected.

So, this generally happens if there is an ADFS server.  There is also another instance that this could happen which is “Pass-Through Authentication” Feature on AAD Connect.

To know more about it,

User sign-in with Azure Active Directory Pass-through Authentication

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication

Long story short

  1. The user tries login to http://portal.office.com or trying to access any office application
  2. Once the credentials are provided by the user, Azure AD, on receiving the request to sign in, places the username and password (encrypted by using the public key of the Authentication Agents) in a queue.
  3. An on-premises Authentication Agent retrieves the username and encrypted password from the queue.
  4. The agent decrypts the password by using its private key.
  5. The agent validates the username and password against Active Directory by using standard Windows APIs, which is a similar mechanism to what Active Directory Federation Services (AD FS) uses. The username can be either the on-premises default username, usually userPrincipalName, or another attribute configured in Azure AD Connect (known as Alternate ID).
  6. The Agent cannot evaluate the request back to Azure AD and failed to respond if the authentication is (success, failure, password expired, or user locked out)

Solution:

The pass-through authenticate is failing for some reason.  This also proves the fact that “Full/Delta Sync” is working because the service account is cloud only account.

Disabled the pass-through authentication on AADConnect using AAD Connect wizard and revert it to password-hash synchronization

 

Microsoft Intune – Things to remember before you use new Azure integrated Intune

As you may already know that Microsoft decided and moved from Classic Intune to Azure integrated Intune.  There are few things that needs to considered before you decide to use Azure integrated Intune for patch management.

  • The app groups that are created in Classic intune are being migrated to Azure integrated Intune.  These groups cannot be used in Classic intune anymore.  If you would like to patch the workstations with the existing group or create a new groups, it wont work – Microsoft acknowledged this as bug and awaiting resolution (This has been resolved now)
  • If there is a policy that exists in the Classic portal and you are using Azure integrated intune, and has a software update ring, then there might be a policy conflict.  Make sure the Classic Intune are removed.
  • Classic Intune can only manage the devices using Intune management agent.  Azure integrated Intune can manage the devices only if the device is enrolled as Mobile Device.  If the agent is present in the workstations, it cant be enrolled as mobile device.  So first thing you should do is to remove the Agent.
  • If the Agent is present in the workstation it cant be enrolled to new Azure integrated Intune.  You have to uninstall the agent, you can use https://gallery.technet.microsoft.com/Uninstall-the-Intune-b42111d1.  This will create a Schedule Tasks.  It may take about 5 to 10 mins.  It uses ProvisioningUtil.exe located under C:\Program Files\Microsoft\OnlineManagement\Common.  If you have custom installation path or if the exe doesn’t exist, then you might need to install the Agent again and run this script again.
  • If you are planning to migrate to Azure integrated Intune from Classic Intune, make sure the device is not listed in the Classic portal.  If the device is visible, then before enrolling, make sure the workstation entry is removed from the Classic portal.  Sometimes you may see entries in both the portal, In that case, you have to remove the device from both the portal, and re-enroll.
  • Finally, version upgrade of windows 10 is not straight forward.

Hope this helps

VJ

ADConnect Sync Issue – Resource/Active forest topology

Recently i’ve encountered an issue with the AD connect. I thought it is worth sharing with others.

Infrastructure

There are 2 forest

1. Forest A and Forest B
2. Exchange is installed on Forest A
4. Forest B users mailbox are on Exchange server which is in the same forest
3. Forest A users mailboxes are on Exchange server which is in the forest B

The typical setup of the organization is below

1665.image_57B62B1E

 

For office 365 migration, AD Connect has 3 connectors

Connector for Forest B – Syncs the user attributes of forest A
Connector for Forest A – Sycns the AD object attributes of Forest A
Connector for Office 365 – Projects the object and their attributes to Azure AD

Forest B users mailboxes are migrated to office 365, Forest A users mailboxes are still on prem.

The reason for projecting the forest A object to AD Azure is to make use of sharepoint online and eventually migrate them to office 365.

Issue:

Ok, the issue here is that, one of user from forest A is assigned with share point but unable to login to it.

Diagnosis:

Sequence of steps that i tried to fix this eventually helped me understand

How AD Connect works.

1. Sharepoint license assinged correctly, and the sites are ok (with the help of sharepoint support i confirmed it is setup correctly comparing with the rest of them)
2. Searched the Forest A connector to see if the user AD attributes are projected – yes it does
3. Searched the Forest B connector to see if the mailbox attributes are projected – yes it does
4. The immutableID of the user object from AD Azure matches the base64 objectGuid of the AD object matches the Forest A (this proves that source anchor is from Forest A)

The catch is, Both the connectors are projecting assuming both are different object

How this supposed to work

1. the attributes of the user from Forest B called msExchMasterAccountSid is matched with the objectGuid attribute of the user in Forest A
2. The AD object on Forest A must be disabled
3. The metaverse should combine the AD attributes from Forest A and Exchange attributes from Forest B and project it to AD Azure

Solutions:

1. Move the user object to non-sync OU on both the forest A & B
2. force the Delta synchronization on all 3 connectors
3. Move the user object in Forest A to syncing OU
4. Run the full synchronization on Connect for forest A, Connector for Office 365
5. Move the user object n Forest B to Syncing OU
6. Run the full synchronization on Connect for forest B

This resolved the problem

But what difference does it make?

Lesson learnt is,

When we create the connector it automatically takes the first priority, so Forest B was project disable object. The second connector created was Forest A, it took the second priority.
For some reason the metaverse cannot combine the disabled Forest B (Exchange attributes) and Forest A ( AD Attributes).
By manually syncing one after the other, the issue was resolved.

But wait, should i do it everytime when new user is created – NO

You can change the priority by yourself using “Rule Editor” which gets installed along with the AD Connect. Keep the priority of the the active forest at the top and the resource forest first to the bottom.

Hope this was useful