Decommission ADFS When Moving To Azure AD Based Authentication

Posted on Leave a commentPosted in ADFS, ADFS 3.0, Azure, Azure Active Directory, Azure AD, AzureAD

I am doing a number of ADFS to Azure AD based authentication projects, where authentication is moved to Password Hash Sync + SSO or Pass Through Auth + SSO. Once that part of the project is complete it is time to decommission the ADFS and WAP servers. This guide is for Windows 2012 R2 installations of ADFS. There are guides for the other versions online.

This guide assumes you were using ADFS for one relying party trust, that is Office 365, and now that you have moved authentication to Azure AD you do not need to maintain your ADFS and WAP server farms.

Compile a list of server names

So first check that these conditions are true. Login to the primary node in your ADFS farm. If you don’t know which is the primary, try this on any one of them and it will tell you the primary node! Run Get-ADFSSyncProperties and you will either get back a list of properties where LastSyncFromPrimaryComputerName reads the name of the primary computer or it says PrimaryComputer.

If you don’t know all your ADFS Server Farm members then you can use tools such as found at this blog for querying AD for service account usage as ADFS is stateless and does not record the servers in the farm directly.

There is no list of the WAP servers in the farm – so you need to know this server names already, but looking in the Event Viewer on an ADFS server should show you who have connected recently in terms of WAP servers.

Get CertificateSharingContainer

On the primary ADFS server run (Get-ADFSProperties).CertificateSharingContainer. Keep a note of this DN, as you will need to delete it near the end of the installtion (after a few reboots and when it is not available any more)

Check no authentication is happening and no additional relying party trusts

Login to each ADFS box and check the event logs (Application). If any service is still using ADFS there will be logs for invalid logins. Successful logins are not recorded by default, but failures are – so if you have failures to login currently happening then something is still using ADFS and so you will not be wanting to uninstall it until you have discovered that.

On the primary ADFS farm member open the ADFS admin console and navigate to Trust Relationships >Relying Party Trusts

image

If all you can see if Microsoft Office 365 Identity Platform (though it has an different name if you initially configured it years and years ago). Device Registration Service is built into ADFS, so ignore that. If you have any others, you need to work on decommissioning these before you decommission ADFS. If you have done the Azure AD authentication migration then the Office 365 Relying Party Trust will no longer be in use. Run Get-MSOLDomain from Azure AD PowerShell and check that no domain is listed as Federated. If all domains are Managed, then you can delete the relying party trust.

Uninstall Additional Connectors etc.

If you have added connectors into ADFS, for example MFA Server tools, then uninstall these first. For example if you have Microsoft MFA Server ADFS Connector or even the full MFA Server installed, then you have this and IIS to uninstall. MFA Server is removed from the control panel (there are a few different things to remove, such as MFA Mobile Web App Service, MFA User Portal etc. Remove the MFA Server piece last. IIS is removed with Remove-WindowsFeature Web-Server. If you uninstall MFA Server, remember to go and remove the servers from the Azure AD Portal > MFA > Server Status area at https://aad.portal.azure.com/ ds

Uninstall the WAP Servers

Login to each WAP server, open the Remote Access Management Console and look for published web applications. Remove any related to ADFS that are not being used any more. Look up Azure App Proxy as a replacement technology for this service. Make a note of the URL that you are removing – its very likely that this means you can remove the same name from public and private DNS as well once the service is no longer needed.

When all the published web applications are removed, uninstall WAP with the following Remove-WindowsFeature Web-Application-Proxy,CMAK,RSAT-RemoteAccess. You might not have CMAK installed, but the other two features need removing.

Reboot the box to complete the removal and then process the server for your decommissioning steps if it is not used for anything else.

Uninstall the ADFS Servers

Starting with the secondary nodes, uninstall ADFS with Remove-WindowsFeature ADFS-Federation,Windows-Internal-Database. After this run del C:\Windows\WID\data\adfs* to delete the database files that you have just uninstalled.

Remove Other Stuff

Your ADFS Service account can now be deleted, as can:

Your DNS entry, internal and external for the ADFS Service, as can:

The firewall rules for TCP 443 to WAP (from the internet), and between WAP and ADFS, as well as:

Any load balancer configuration you have. Finally, you can:

Remove the certificate entries in Active Directory for ADFS. If you have removed ALL the ADFS instances in your organization, delete the ADFS node under CN=Microsoft,CN=Program Data,DC=domain,DC=local. If you have only removed one ADFS farm and you have others, then the value you recorded at the top for the certificate is the specific tree of items that you can delete rather than deleting the entire ADFS node.

Hardware Tokens for Office 365 and Azure AD Services Without Azure AD P1 Licences

Posted on 2 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, Multi-Factor Authentication, token2

A recent update to Azure AD Premium 1 (P1) licence has been the use of hardware tokens for multi-factor authentication (MFA). This is excellent news if your MFA deployment is stuck because users cannot use phones on the shop floor or work environment or they do not want to use personal devices for work activities. But it requires a P1 licence for each user. Now a P1 licence gives lots of stuff in addition to hardware token support for MFA, such as (but not exclusively) Conditional Access, which is a better way to implement MFA than when used without P1, which requires MFA in all circumstances and for all apps from all locations.

But if you want MFA in all circumstances and for all apps from all locations, and also need hardware tokens, this is where programable tokens come into play. I recently purchased a miniOTP-2 token from Token 2 (www.token2.com) and they provided me with a C300 token as well so that I could write this blog post.

In the scenario that I am going to describe here, I have two different programable tokens and I will walk through the MFA registration process for a user (using the new user interface for this service that was released end of Feb 2019).

IMG_20190226_095155

Enabling the new MFA Registration Process

Open the Azure AD Portal from https://aad.portal.azure.com, click Azure Active Directory from the primary menu and then select User settings from the sub-menu. Under Access panel, click Manage settings for access panel preview features. You will see the following:

image

In this I have previously turned on the preview features for registering and managing security info that was rollout out early 2018 and now I can see a second option for the same, but called refresh.

Set both of these options to All (or a selected group if you want to preview for a subset of users initially). Click Save.

For what follows, it will work even if you have None set for both options, just the screenshots will look different and the latest refresh of this feature is much easier for users to work with – so I recommend it is turned on for both options.

Configure MFA Settings for your Tenant

In the Azure AD portal sub-menu click MFA under Manage MFA Server and click Additional cloud-based MFA settings under Configure. This opens another tab in your browser where you will see the Multi-Factor Authentication / Service Settings.

Under Verification Options ensure that Verification code from mobile app or hardware token is enabled. Other options such as “app passwords”, “skip for federated users”, “trusted IPs” (available if you ever once had the AAD P1 licence on your tenant even if you do not have it now) and “remember multi-factor authentication” can be set to your requirements.

Register a Programable MFA Token for a User

Once you have MFA settings configured you can enable the service for a user and have the token registered for the user. If you have a P1 licence you upload the token serial number to Azure AD, but if you do not have a P1 licence then you need to use a programable token as these appear to act just like authenticator apps you get on your phone.

In Azure AD you can register a user’s token by logging in as the user (they would do this for you) by visiting https://aka.ms/mfasetup. End to end this process takes about 10 seconds – so its very possible to add this process into new user joining procedures or have help desk visit the user or the other way around. This process needs an NFC burner app and device (Android phone is good), but don’t require the user to do this themselves using their phone – burn the token for them using a help desk PC or phone. If you get the end user to walk through all these steps you will confuse them totally!

The new UI for end user security settings:

image

As mentioned above, the UI you see is based upon the User settings options in Azure AD. If you have just the original refresh enabled, you will see the following instead:

image

In the first of the above two screenshots I have already registered some MFA devices. If the user has never registered a device before then they will see the following when browsing to https://aka.ms/mfasetup from the initial login and then the MFA registration page, with the registration process ready to start:

image image

If you have already registered some security info, then you will be able to add a hardware token from the + Add Method button and selecting Authenticator App and clicking Next.

image

The initial steps will show you the following dialog, depending upon if you are a new user (on the left) or adding a new MFA method (on the right):

image image

You are walked through the process of installing the Microsoft Authenticator app on your phone. In this case though, we have a hardware token instead of the app, and so you need to click I want to use a different authenticator app instead. The Microsoft Authenticator App supports push notifications, which hardware tokens do not, and so the QR code provided for the Microsoft Authenticator app will not work for hardware or other authenticator apps.

image image (QR code intentionally blurred)

Now you need to scan the QR code using the Token 2 Android app or click Can’t scan image and copy and paste the secret key into the Token 2 Windows app. Links to the apps are available from the Token 2 website software page (with the Windows app shown below):

image

Click the QR button (or Scan QR button if using the NFC Burner 2 software) and scan the QR code on the screen. This enters the seed in HEX into the app. If you need to enter the QR code by hand, click enter Base32 and type in the secret key value that you get under the Can’t scan image link.

Next, turn the hardware token on (it will remain on for 30 seconds) and hold it to the NFC reader on your Android device (usually next to the camera) or plugged into your PC.

IMG_20190302_160227

Click the Connect button (or Connect Token depending upon the app you are using) – one of the Android apps are shown below:

Screenshot_20190302-173645

Then finally click burn seed.

Screenshot_20190302-173653

Turn off the token and turn it back on again – this displays the next valid code. The code that was displayed when the token was first turned on and before the new secret was burned to the device is not valid.

Click Next on the registration wizard on the computer screen. You are asked to enter the code displayed on the token. Azure AD has a 900 second range for codes, so any code displayed in the last 7 or so minutes should be valid to use

image

Success – if not, turn the token off and on again and try again. If not, go back, scan the code again and burn to the device another time – you are not restricted on the number of times you do this (though doing this wipes previous users of the token from using it again).

image

Click Done and see your first method of providing MFA shown to the user.

image

I recommend you add the users phone (for a call or text) as a second method at this point (in case they loose the token, they have a second route in). The user experience for when adding a phone looks as follows:

image

It is a shame we cannot rename the MFA method – that would be useful, as we could indicate the token name/type and then login to Azure AD could ask for this token by name.

If you were adding a new token to a user with existing MFA methods already in place, you end up in a very similar place:

image

Success – a new “app” added:

image

Then at next login when going to the MFA registration page, you need to enter your code:

image

Note that you don’t need the code yet for logging into Office 365 and Azure AD generally – you have to enable MFA for that and that is the next step.

Enforcing MFA for User

For all other logins apart from the MFA registration page, you need to finish by enforcing MFA for the user. If you have a P1 licence and Conditional Access then this will happen based on the rules, but where you don’t have AAD P1 licence, then you need to enforce MFA for all logins. Do this by browsing to the multi-factor authentication and users page via the Office 365 admin portal > active users > ellipses button > setup multifactor authentication:

Search for your user:

image

Once you have found the user to enable, select the user and then click the Enable hyperlink:

image

Followed by enable multi-factor authentication

image

The comment about “regularly sign in through the browser” is not valid for modern authentication supporting apps such as Microsoft Teams or where you have enabled Modern Authentication for Skype for Business Online and Exchange Online (you need to do this if your tenant exists from before August 2017)

image

Finally for completion, there is an MFA setting called Enforce. Enforce requires MFA for all logins including rich client applications that do not support MFA – therefore if you have modern authentication enabled and are using Outlook 2013 (with the Modern Auth settings for Outlook 2013 turned on) or Outlook 2016 and later then having the end user remain in Enable mode is fine. If you are using older clients that do not support MFA then Enforce mode will force them to use App Passwords for non-browser apps, and you want to try and avoid that.

Therefore we need to take the user to a minimum of Enable mode in Office 365 MFA so that MFA is triggered for all logins. This step is probably done after hardware token registration as when we set up the token for the user or when we sent the user through the registration workflow we did not first enabling MFA for the user – therefore the user is registered for MFA but not required to use it to login.

Set the user to Enable mode to trigger MFA for all logins:

image

Token2 Hardware OAuth Tokens and Azure AD Access

Posted on 2 CommentsPosted in active directory, Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, phone factor, token2

This blog post walks through the process of logging into Azure AD resources (Office 365, other SaaS applications registered in Azure AD and on-premises applications that utilise Azure AD App Proxy).

First step is to order your desired hardware. For this article we are looking at the devices manufactured by Token2 (www.token2.com). These include credit card style and dongle type devices. The options are available at https://www.token2.com/site/page/product-comparison

For the purposes of this blog post I have been using the TOTP emulator on the Token2 website. This allows you to create virtual TOTP devices and step through and test the entire process without buying a physical token. The TOTP device emulator can be found at https://www.token2.com/site/page/totp-toolset. Each time you browse to this site a new device is emulated, but using key=XXXX, where XXXX is the 32 character device seed. Longer testing will require you to keep a record of the seed ID and use it in the emulator, or keep the browser window open.

Step 1: Order Devices

For this, I am using the emulator mentioned above, but you would order a number of devices and upon arrival request the unique secret identifiers for each device over encrypted email. In Feb 2019 a programmable device with time sync is being released which will allow you to set the secrets yourself and ensure that clock drift on the device is not a reason for them to stop working after a few years!

The secret is required for upload to Azure AD and is required in the form of a CSV file with six columns:

upn,serial number,secret key,timeinterval,manufacturer,model

For example, it could look like this for a two emulated devices:

upn,serial number,secret key,timeinterval,manufacturer,model
user1@token2.com,2300000000001,BMUOZOAFVH4ZYRXU7SFRIIQ3FQNKTDVL,30,Token2,miniOTP-1

user2@token2.com,2300000000002,R5AGIKGVCCGIV275IDTCI2HWDQK3PK2R,30,Token2,miniOTP-1

Ensure each UPN in the first column matches the device you are issuing to the user and upload the CSV file to Azure AD. This is done from Azure Portal > Azure Active Directory left menu > MFA (in Security area) > OAUTH tokens (in settings area):

image

Click Upload and browse for your CSV file. As long as there are no errors it will upload fine. Errors are displayed in the notifications area. Once the upload is complete click Refresh to see the imported hardware tokens. Tokens assigned to users that do not exist will appear after the user is created, if the user is created within 30 days.

I have in the below screenshot uploaded one token for a test user.

image

The token needs activating before it can be used. Activation is to confirm the token works and so you will need the next six digit sequence from the device and so have physical access to the device. End user activation is planned, but as of writing in Jan 2019 the administrator needs to activate the hardware token.

Click Activate and enter the current TOTP six digit number. The CSV file contains information about the time change for the device, which is 30 seconds for these Token2 devices, and so you need to enter the current, previous or next ID (next ID is shown in the emulator and not on the hardware token).

image

Click Activate button when the six digit code is entered. The green ticky ticky next to the number just means you have entered a six digit number, and not that it is the correct number!

After activation you will see the Activated column ticked.

image

You can now distribute the token to the user.

Step 2: Require token for login

Other blog posts and documentation on the internet cover the requirements for forcing the user to use an MFA device, so here I will just cover what is different when tokens are used. Firstly the user does not need to register their device – the upload of the CSV file and the activation of the token by the administrator covers this step. This does mean though that the user needs the token before they next are required to login with the MFA device or they will not be able to login. Therefore distribution of token following activation, or activation before MFA requirement is currently needed. End user activation which is coming soon will reduce this distribution gap.

Secondly, the code from an Authenticator app (such as Microsoft Authenticator or Google Authenticator) can be used as well as the code from the hardware token device (if the app is registered as well). Microsoft allow multiple devices to provide codes, so the user message on-screen at login will not say “Enter the code from your token2 device” but currently says “Please type in the code displayed on your authenticator app from your device”, but the current code from your hardware device and not only a registered app will work here as well. This is probably the most confusing stage of the process. The hardware token works wherever authenticator app is displayed – maybe this will change.

Finally, the user will only be required for an MFA login if either MFA is enabled for the account or conditional access enabled and the login or application access triggers an MFA requirement. The second of these is the better one to use. The admin configuration to force the user to enter their token one time code though is as follows:

  1. Ensure that MFA service settings allows verification code from mobile app or hardware token as shown:
    image
  2. Ensure that the IP range where MFA is skipped is not the range the user is currently located on, otherwise the user will not be prompted for their MFA token. This IP range is configured in the above settings as well.
  3. Ensure that the user requires MFA to login from the MFA users page as shown. Select the user and click Enable:
    image  image
  4. Or, if using Conditional Access, that the Grant option includes MFA as one of the requirements as shown:#
    image
  5. In the first step above you can see that phone calls, text and notification through app are all also enabled. These do not need to be enabled for the hardware device to work.
  6. The user needs an Azure AD P1 or P2 licence to use hardware tokens.

Step 3: The user login experience

When the user logs in or accesses an app that is MFA restricted via Conditional Access they will see the MFA login prompt as shown:

image

The code entered needs to come from their hardware device, as shown below:

image

The token changes every 30 seconds and is valid for a short while either side of the time it is displayed for on the device. Over time tokens will suffer from clock skew and eventually stop working. The new token2 programmable tokens available in Feb 2019 can have their clocks resynced to fix this issue.

As mentioned above, any registered authenticator app or hardware token uploaded against the user will work – the UX asks for an app at present, maybe this wording will get more clarification when the user has a token registered as well.

Step 4: User experience

Apart from the login, the other place where a user will see their token listed is the My account > Security and Privacy option (click your picture in an Office 365 app to see My account menu). If you have MFA enabled for the user (not just Conditional Access) then the user will see “Additional security verification” on the Security & Privacy page. Here is says “Update your phone numbers used for account security” – but this will list your hardware token as well. This is shown below:

image

In the above you can see that the user has an iPhone as well as the token, where the hardware token ID matches the serial number on the device that they hold, as well as a phone in this scenario. This allows the user to have a backup MFA method of more than one authenticator (Microsoft Authenticator on iPhone or MFA by phone call in this case) as well as the Authenticator app or hardware token. Your users can now have up to five devices in any combination of hardware or software based OATH tokens and the Microsoft Authenticator app. This gives them the ability to have backup devices ready when they need them and to use different types of credentials in different environments.

The use of a hardware token and its OAUTH code currently still requires a password before MFA token. Password-less token only is expected later in 2019.

Read Only And Attachment Download Restrictions in Exchange Online

Posted on Leave a commentPosted in Azure Active Directory, Azure AD, download, exchange, exchange online

Microsoft have release a tiny update to Exchange Online that has massive implications. I say tiny in that it take like 30 seconds to implement this (ok, may 60 seconds then).

When this is enabled, and below I will describe a simple configuration for this, your users when using Outlook Web Access on a computer that is not compliant with a conditional access rule in Azure AD, will result in OWA that is read only – attachments can be viewed in the browser only and not downloaded. There is even a mode to have attachments completely blocked.

So how to do this.

Step 1: Enable the OwaMailboxPolicy New Setting

Only users whose OWAMailboxPolicy have the ConditionalAccessPolicy set to ReadOnly or ReadOnlyPlusAttachmentsBlocked are impacted by this feature. For example if you wanted a subset of users to always have this restriction regardless, but not other users then you would create a new OwaMailboxPolicy and set the ConditionalAccessPolicy setting. Once that is done you would apply the policy to the selected users.

In my example I am just going to update the default policy, becuase I want read only view for all users who fall out of the conditions of the policy. So in Exchange Online PowerShell I run the following:

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnly

This, once the conditional access policy takes effect will restrict downloads in OWA. The second option is to use ReadOnlyPlusAttachmentsBlocked instead of ReadOnly. This blocks attachment viewing as well. I understand other options and therefore values for this property are coming. The value “Off” turns off the restrictions again. “Off” is the default value.

Step 2: Create a Conditional Access Policy in Azure AD

You need an Azure AD Premium P1 licence for this feature.

Here I created a policy that applied to one user and no other policy settings. This would mean this user is always in ReadOnly mode. In real world scenarios you would more likely create a policy that applied to a group and not individual users and forced ReadOnly only when other conditions such as non-compliant device (i.e. home computer) where in use.

The steps for this are:

imageimageimageimage

The pictures, as you cannot create the policies in the cmdline, are as follows:

a) New policy with a name. Here it is “Limited View for ZacharyP”

b) Under “Users and Groups” I selected my one test user. Here you are more likely to pick the users for whom data leakage is an issue

c) Under “Cloud apps” select Office 365 Exchange Online. I have also selected SharePoint, as the same idea exists in that service as well

d) Under Session, and this is the important one, select “Use app enforced restrictions”. For Exchange Online, app enforced restrictions is the value of ConditionalAccessPolicy for the given user.

Step 3: View the results

Ensure the user is licenced to have a mailbox and Azure AD Premium P1 and ensure they have an email with an attachment in it for testing.

In the screenshot you can see circled where the Download link is normally found:

image

And where the attachment is clicked, there is now a greyed out Download button and a banner is seen in both views telling the user of their limited access.

image

The new user interface to OWA looks as follows:

image

With ReadOnlyPlusAttachmentsBlocked set as the ConditionalAccessPolicy value, the attachment cannot be viewed. This is what this looks like (new OWA UI):

image

And SharePoint and OneDrive, just because it is very similar!

For reference, in the SharePoint Admin Centre and Policies > Access Control > Unmanaged Devices, here you turn on “Allow limited web-only access” or “Block access” to do something similar in SharePoint as shown:

image

In the classic SharePoint Admin Center it is found under that Access Control menu, and in SharePoint PowerShell use Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess

Turning the settings on in SharePoint creates the Conditional Access policies for you, so for my demo I disabled those as the one I made for ZacharyP included SharePoint as well as a service.

This is as shown for SharePoint – the banner is across the top and the Download link on the ribbon is missing:

image

And for OneDrive, which is automatic when you turn it on for SharePoint:

image

Improving Password Security In the Cloud and On-Premises

Posted on 1 CommentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, EM+S, enterprise mobility + security, microsoft, Office 365, password, security

Passwords are well known to be generally insecure the way users create them. They don’t like “complex” passwords such as p9Y8Li!uk%al and so if they are forced to create a “complex” password due to a policy in say Active Directory, or because their password has expired and they need to generate a new one, they will go for something that is easy to remember and matches the “complexity” rules required by their IT department. This means users will go for passwords such as WorldCup2018! and Summ3r!!. Both these exceed 8 characters, both have mixed case, both have symbols and numbers – so both are complex passwords. Except they are not – they are easy to guess. For example, you can tell the date of this blog post from my suggestions! Users will not tend to pick passwords that are really random and malicious actors know this. So current password guidance from NIST and UK National Cyber Security Centre is to have non-expiring unknown, not simple passwords that are changed on compromise. Non-expiring allows the user to remember it if they need to (though a password manager is better) and as it is unknown beforehand (or unique) means its not on any existing password guess list that might exist.

So how can we ensure that users will choose these passwords! One is end user training, but another just released feature in the Microsoft Cloud is to block common passwords and password lists. This feature is called Azure AD Password Protection. With the password management settings in Azure AD, cloud accounts have been blocked from common passwords for a while (passwords that Microsoft see being used to attempt non-owner access on accounts) but with the password authentication restrictions you can link this to block lists and implement it with password changes that happen on domain controllers.

So how does all this work, and what sort of changes can I expect with my passwords.

Well what to expect can look like this:

image

Note all the below is what I currently know Microsoft do. This is based on info made public in November 2018 and documented at https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad and is subject to change as Microsoft’s security graph and machine learning determines change is needed to keep accounts secure.

Password Scoring

First, each password is scored when changed or set by an administrator or a user on first use. A password with a score less than 5 is not allowed. For example:

spring2018 = [spring] + [2018] = 2 points

spring2018asdfj236 = [spring] + [2018] + [asdf] + [f] + [j] + [2] + [3] + [6] = 8 points

This shows that common phrases (like Spring and 2018) can be allowed as part of password that also contains stuff that is hard to guess. In this, the asdf pattern is something straight from a Qwerty keyboard and so gets a low score. In addition to the score needing to exceed 5, other complexity rules such as certain characters and length are still required if you enforce those options. Passwords are also “normalized”, which lower cases them and compares them in lower case – so spRinG2018 is as weak as spring2018. Normalization also does common character replacesments such as $=s, so $PrinG2018 is the same as spring2018 and also just as weak!

You name is not allowed in any password you set and the logic applies to an edit distance of 1 character – that is if “spring” is a blocked word then “sprinh” would also be blocked, h being one character away from g.

Common and Blocked Lists

Microsoft provide the common password lists, and these change as Microsoft see different passwords getting used in account attacks. You provide a custom blocked list. This can contain up to 1000 words, and Microsoft apply fuzzy logic to yours and the common list. For example we added all our office locations as shown:

image

This means that both capetown and C@p3t0wn would be blocked. The @=a, the 3=e and the 0=o. So the more complex one is really not complex at all as it contains common replacements.

In terms of licences, the banned password list that Microsoft provides is licence free to all cloud accounts. You need AAD Basic if you want to add your own custom banned password list. For accounts in Windows Server Active Directory you need the Azure AD Premium (P1) licence for all synced users to allow downloading of the banned password list as well as customising it with your words so that Active Directory can apply it to all users on-premises to block bad passwords (even those users not synced to AzureAD).

Hybrid Password Change Events Protected

The checks on whether a password change should be stopped is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication, though changes to the custom banned password list may take a few hours to be applied to the list that is downloaded to your domain controllers.

On-Premises Changes

There is an agent that is installed on the domain controllers. Password changes are passed to the agent and it checks the password against the common list and your blocked list. The agent does the password check, and it checks it against the most recently downloaded list from Azure AD. The password for on-premises is not passed up to Azure AD, the list is downloaded from Azure AD and processed locally on the domain controller. This download is done by the Azure AD password protection proxy. The list is then downloaded once per hour per AD site to include the latest changes. If your Azure AD password protection proxy fails, then you just use the last list that was successfully downloaded. Password changes are still allowed even if you lose internet access.

Note that the Azure AD password protection proxy is not the same as the Pass-Through Authentication agent or the AAD Connect Health agent. The Azure AD password protection proxy can though be installed on the same servers as the PTA or Connect Health agent. Provisioning new servers for the proxy download service are not required.

The Azure AD password protection proxy wakes up hourly, checks SYSVOL to see the timestamp of the most recently downloaded copy and decides if a new copy is needed. Therefore if your intra-site replication is within the hour, proxy agents in other sites might not need to download the list as the latest is already available via DFSR between the domain controllers.

The Azure AD password protection proxy does not need to run on a domain controller, so your domain controllers do not need internet access to obtain the latest list. The Azure AD password protection proxy downloads the list and places it in SYSVOL so that DFSR replication can take it to the domain controller that needs it.

Getting Started

To set a custom password block list, in the Azure Portal visit the Azure AD page, click Security and then click Authentication Methods (in the Manage section). Enter your banned passwords, lower case will do as Microsoft apply fuzzy logic as described above to match your list to similar other values. Your list should include common words to your organization, such as location, office address keywords, functions and features of what the company does etc.

For Active Directory, download the agent (from the Microsoft Download Center) to one or more servers (for fault tolerance). These will download the latest list and place it in SYSVOL so that the domain controllers can process it. Two servers in two sites would probably ensure one of them is always able to download the latest copy of the list.

The documentation is found at https://aka.ms/deploypasswordprotection.

Microsoft suggests that any deployment start in audit mode. Audit mode is the default initial setting where passwords can continue to be set even if they would be blocked. Those that would fail in Enforce mode are allowed in Audit mode, but when in audit mode entries in the event log record the fact that the password would fail if enforce was turned on. Once proxy server(s) and DC agents are fully deployed in audit mode, regular monitoring should be done in order to determine what impact password policy enforcement would have on users and the environment if the policy was enforced.

This audit mode allows you to update in-house policy, extend training programs and offer password advice and see what users are doing that would be considered weak. Once you are happy that users are able to respond to an password change error because the password is too weak, move to enforce mode. Enforce mode should kick in within a few hours of you changing it in the cloud.

Installing the Proxy and DC Agent

Domain Controllers need to be running Windows Server 2012 and later, though there are no requirements for specific domain or forest functional levels. The Proxy software needs to run on a Windows Server 2012 R2 or later server and be running .NET 4.6.2 or later. Visit the Microsoft Download Center to download both the agent and the password protection proxy. The proxy is installed and then configured on a few (two at most during preview) servers in a forest. The agent is installed on all domain controllers as password changes can be enacted on any of them.

To install the agent, run AzureADPasswordProtectionProxy.msi on the server that has internet connectivity to Azure AD. This could be your domain controller, but it would need internet access to do this.

To configure the agent, you need to run once Import-Module AzureADPasswordProtection followed by Register-AzureADPasswordProtectionProxy and then once the proxy is registered, register the forest as well with Register-AzureADPasswordProtectionForest all from an administrative PowerShell session (enterprise admin and global admin roles required). Registering the server adds information to the Active Directory domain partition about the server and port the proxy servers can be found at and registering the forest settings ensure that information about the service is stored in the configuration partition.

Import-Module AzureADPasswordProtection
Get-Service AzureADPasswordProtectionProxy | FL
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

If you get an error that reads “InvalidOperation: (:) [Register-AzureADPasswordProtectionProxy], AggregateException” then this is because your AzureAD requires MFA for device join. The proxy did not support MFA for device join during the early preview but that should now be resolved – make sure you are using the latest download of the agent and proxy code. you need to disable this setting in Azure AD for the period covering the time you make these changes – you can turn it back on again (as on is recommended) once you are finished configuring your proxy servers. This setting, should you need to disable it, is found at:

  • Navigate to Azure Active Directory -> Devices -> Device settings
  • Set “Require Multi-Factor Auth to join devices” to “No”
  • As shown
    image
  • Then once the registration of your two proxies is complete, reverse this change and turn it back on again.

Once at least one proxy is installed, you can install the agent on your domain controllers. This is the AzureADPasswordProtectionDCAgent.msi and once installed requires a restart of the server to take its role within the password change process.

The PowerShell cmdlet Get-AzureADPasswordProtectionDCAgent will report the state of the DCAgent and the date/time stamp of the last downloaded password block list that the agent knows about.

image

Changes In Forest

Once the domain controller the agent is installed on is rebooted, it comes back online, finds the server(s) running the proxy application and asks it to download the latest password block list. The proxy downloads this to C:\Windows\SYSVOL\domain\AzureADPasswordProtection. Older versions of the proxy and agent used a folder called
{4A9AB66B-4365-4C2A-996C-58ED9927332D} under Policies folder. These versions of the agent stop working in July 2019 and need to be updated to the latest release.

In the Configuration partition at CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=domain,DC=com some settings about the service are persisted. If the domain controller has the agent installed then

CN=AzureADConnectPasswordPolicyDCAgent,CN=<DomainControllerName>,OU=Domain Controllers,DC=domain,DC=com is created.

And then on each domain controller, in the Event Viewer, you get Application and Services Logs > Microsoft > AzureADPasswordProxy with DCAgent on the DC’s and ProxyService on the proxy servers. The EventID’s are documented at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-monitor.

The monitoring Event ID will cover things like user password change differently than admin password set. This allows you to audit who (end user or service desk) is setting weak passwords.

Once the proxy starts to work, the above folder starts to get content. In my case in the preview it took over 2 hours from installing the proxy as well as the documented installation and configuration PowerShell cmdlets listed above to get the proxy to download anything. The above listed Configuration folder contained some cfge files and the above listed PasswordPolicies contains what I assume is the downloaded password block list, compressed as its only 12KB. This is the .ppe file and there is one of these per hour downloaded. Older versions of this download are deleted by the proxy service automatically.

Audit Mode

Using the above Event ID’s you can track the users who have changed to weak passwords (in that they are on your or Microsoft’s banned password list) when the user or admin sets (or resets) the users password. Audit mode does not stop the user choosing the password that would “normally have been rejected” but will record different Event IDs depending upon the activity and which block list it would have failed against. Event id DCAgent/30009 for example has the message “The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.”. This message is a failure against Microsoft’s list on password set. The user doing a password change and the Microsoft list gets DCAgent/30010 Event ID recorded instead.

Using these two Event ID’s along with DCAgent/30007 (logged when password set but fails your custom list) and or DCAgent/30008 (password changed, fails your custom list) allows you to audit the impact of the new policy before you enforce it.

Enforce Mode

This mode ensures that password set or change events cannot have passwords that would fail the list policies. This is enabled in the password policy in Azure AD as shown:

image

Once this is enabled it takes a few hours to be picked up by the proxy servers and then for the agent to start rejecting banned passwords.

When a user changes their password in enforce mode they get the following error (different graphic depending upon Windows versions). If the admin changing the password uses a blocked password then they see the left hand graphic as well (Active Directory Users and Computers).

image
image

or

This is no different to the old error you get when your password complexity, length or history is not met. Therefore there is no indication to the user that the password they chose might be banned rather than not allowed for the given reasons. So though password policy with a banned list is an excellent step forward, there needs to be help desk and end user awareness and communications (even if they are just a simple notification) as the user would not be able to tell from the client error they get. Maybe Microsoft have plans to update the client error?

Password changes that fail once enforce mode is enabled get Event ID’s such as DCAgent/30002, DCAgent/30003, DCAgent/30004 and DCAgent/30005 depending upon which password list the fail happened against and the method of password set or change. For example when I used the password Oxford123, as “oxford” is in the custom banned password list, Event ID 30003 returns “The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy”. As mentioned above, the sequence of 123 following the banned word is not enough to make to score more than 5 points and so the password change is rejected.

On the other hand, 0xf0rdEng1and! was allowed as England was not on my banned list an so although my new password contained a banned word, there were enough other components of the password to make it secure enough. Based on the above mentioned scoring of 5 or more is required to have a password accepted, [Oxford] + [E] + [n] + [g] + [1] + [a] + [n] + [d] + [!], a total of 9. 9 >= 5 and so the password is accepted.

Finally, when testing users, other password policies like the date that the password can next be changed and “user cannot change password” property etc. will take effect over the banned password list. For example, if you have a cannot change password for 5 days setting, and you set the users password as an administrator – that will work or fail based on the password you enter, but if you change the password as the user within that time period, that will fail as five days have not gone by and not because the user picked a guessable password.

Azure AD Single Sign-On Basic Auth Popup

Posted on Leave a commentPosted in AADConnect, AADSync, Azure Active Directory, Azure AD, AzureAD, conditional access, microsoft, modern authentication, SSO

When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is https://autologon.microsoftazuread-sso.com and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).

So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:

image

It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!

The URL is aadg.windows.net.nsatc.net. Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.

Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.

It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.

This issue is listed in the Azure AD SSO known issues page at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso. The reason why Enhanced Protected Mode does not work with Azure AD SSO is that whilst Enhanced Protected Mode is enabled, Internet Explorer has no access to corporate domain credentials.

Configuring Hybrid Device Join On Active Directory with SSO

Posted on 15 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, device, device registration, hybrid

The instructions from Microsoft at https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup are missing some of the steps on setting up hybrid device join to Azure AD. This is a complete list of steps when Pass-Thru auth with SSO is enabled on the domain.

  1. Enable SSO – this is covered elsewhere. You can also do hybrid device join on a federated domain, though this is not covered here.
  2. On your AADConnect server ensure that the MSOnline PowerShell add in is installed – this is the AdministrationConfig-3.msi executable that is needed to run cmdlets like Get-MSOLUser. Is only supported by the MSOnline PowerShell module version 1.1.166.0. To download this module, use this link
  3. Open an administrative PowerShell
  4. cd 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep'
  5. Import-Module .\AdSyncPrep.psm1
  6. This will enable the AD module and import some scripts for device writeback and device registration. We are looking at device registration here
  7. $aadAdminCred = Get-Credential

    #Enter a global admin credential

  8. Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred

    #[connector account name] is the name of your domain (domain.local for example) as shown in the AADConnect Synchronization Service Manager –

  9. You should see the message “Initializing your Active Directory forest to sync Windows 10 domain joined computers to Azure AD.” followed by “Configuration Complete”. Errors about Azure Registration mean you are running the wrong version of the Azure AD PowerShell cmdlets
  10. The required settings in AD (for one forest) are now done. If you have multiple forests, return to the above referenced document and run the script to register the Devices Registration Configuration node to AD
  11. If you have conditional access available (have at least one Azure AD Premium licence assigned to your admin account) then you can add Trusted Sites to Azure AD to control where MFA prompts for device join will happen outside of. Add each office public NATed IP address with /32 (or whatever is needed at the end) into Azure Active Directory (under portal.azure.com) > Conditional Access > Named Locations > New Location
    image
  12. Add the same IPs to the “Configure MFA trusted IPs” link on the same page that you see the IP’s listed above
  13. Your list of devices under Azure Active Directory should now increase as users reboot Windows 10 1703 machines and later. See the above document about the GPO setting needed to role this out to older versions of Windows (Workplace Join settings)

Azure AD SSO and Disabled Computer Accounts

Posted on 5 CommentsPosted in Authentication, Azure Active Directory, Azure AD, Office, Office 365, SSO

When you set up Azure AD SSO, the Azure AD Connect application creates a computer account called AZUREADSSOACC. Do not disable this account, or SSO stops working.

I’ve had a few clients in the past week disable this when generally disabling all the computer accounts that have not logged in for X days.

Therefore if you have Azure AD SSO enabled, I suggest updating your documentation on disabling computer accounts – ‘cause not all computer accounts actually login as computers (I’m thinking Cluster services here as well) and consider actually whether or not disabling accounts for computers that are not logging in any more is necessary.

Then also take the AZUREADSSOACC account and set a description on it saying do not disable!

image

AADConnect Password Reset Date Sync Issues

Posted on 2 CommentsPosted in AADConnect, active directory, Azure Active Directory, Azure AD, sync error

Got this error the other day at a client and found nothing listed on Internet search for it, which of course means only I have this issue! But even so, lets get to see what it means and how to fix it.

The error turned up in the AADConnect tool and it reported sync-generic-failure on the Delta Synchronization stage when pulling data from Active Directory.

Error in evaluation of expression: IIF(IsPresent([pwdLastSet]),CStr(FormatDateTime(DateFromNum([pwdLastSet]),”yyyyMMddHHmmss.0Z”)),NULL) 
. Sync Rule: In from AD – User AccountEnabled
Destination: pwdLastSet

Following the above error was the entire stack dump of the issue (a few pages of errors) which are visible by clicking the sync-generic-failure link in AADConnect and clicking the Stack Trace button. Buried inside the stack dump are a few “InnerException” errors. These point out the real cause of the issue.

InnerException=>
Argument 1 to function DateFromNum is out of range.

and

InnerException=>
Not a valid Win32 FileTime.
Parameter name: fileTime

   at System.DateTime.FromFileTimeUtc(Int64 fileTime)
   at SyncRuleExpressions.FunctionLibrary.DateTimeFunctions.DateFromNum(Value[] arguments)

This shows that the user in question (which is listed by DN in the stack dump) has an invalid value for the pwdLastSet attribute.

So we opened up the user and viewed the pwdLastSet value and it read -1

Now this value is valid – it is used in code and scripts to set this attribute to the current date and time, as normally this value is set by a script and so setting -1 means that you want the time for the last password set to be now.

In my clients domain either the script failed or something else did not work, and the property was set and stayed at -1 in the directory. Viewing this attribute in adsiedit showed it to be <never> and double-clicking this attribute showed the value to be -1.

In the end the fix was simple – we retyped -1 into the field in adsiedit and clicked OK. This time the attribute updated to the current date and time. Now that the attribute was a valid date/time, the AADConnect sync rule worked and the object was synced to Azure AD.

OU Filtering in AADConnect–What They Grey Boxes Mean

Posted on Leave a commentPosted in AADConnect, az, Azure Active Directory, Azure AD, dirsync, Office 365

So I had the chance to check this today. If you do OU filtering in the DirSync tools you will get an OU structure with various grey boxes in it. Here is an example:

image

It appears that both clip_image003and image are options in the sync tool. You get the first (grey with a tick ) if you select that box and untick some child objects. You get the second (grey box, no tick) if you unselect the parent and then individually select child OU’s.

If you do the second option (and get image)and then add a new OU under the parent it is not selected in the sync engine by default. Unfortunatly you cannot do this for the root of the domain during initial setup of AADConnect, as you need to select the domain in the provisioning wizard before unselecting OU’s). You can later go into the sync tool and change the domain to default unselected (image) by unselecting everything and then just selecting the OU’s you need. In this way you can be sure that later OU’s are not auto selected for syncing.