ADFS

ADFS Claim / Additional Authentication rules can appear very complex and confusing, and that’s because they are! One thing that tripped me up recently is related to the issue section of a claim rule whereby MFA is specified. During a project, I created a rule from a template I had used for another customer. Upon saving the rule I found that it didn’t apply MFA as I was expecting, and instead caused an error message in ADFS during logon attempts.

The rule I had used was issuing a claim for the Azure MFA Server rather than the Azure MFA Cloud Service. To clarify, the difference in the claim type is as follows:

I don’t usually do this, but I love this post so much I needed to tell my readers about it. ADFS has 3 certificates assigned to it, and it’s uncommon for the token-signing and token-decrypting certificates to be trusted, 3rd party certs. They are usually left as self-signed certs. Their use scenario doesn’t demand that 3rd party certs are used, and in all honesty using these would provide no tangible benefit. So whenever I deploy ADFS, only the Service Communications certificate uses a trusted 3rd party cert.

The renewal of these self-signed certificates can be a pain and can easily be forgotten until it’s too late, so whenever I deploy ADFS for a customer, I always set the duration of these certificates to 100 years, using this handy guide!

Azure MFA is a great concept in itself, especially when applied to Office 365 using ADFS, but quite often there is a need for granular control over when MFA is actually applied. There are GUI options for enabling MFA just for extranet requests, but this poses several problems:

Issues with Autodiscover requests – these are proxied from Office 365 and thus always route via the ADFS Proxy servers. This means that all Autodiscover requests, no matter where the client is located, appear to originate from the internet, which poses a problem when applying MFA to only be enforced for Extranet requests, as Outlook clients will be prompted for MFA even when inside the Intranet.

Mobile Applications – These will likely always come from Extranet locations. It is undesirable, and in some cases unsupported, for these applications to use MFA whenever they are opened.

Skype for Business client – It is not desired to require MFA when Skype for Business is opened from the Extranet.

In addition to the MFA Server configuration itself, a custom ADFS claim needs to configured to force MFA if certain conditions are present. This can be very fiddly and currently there are not any GUI based tools to achieve this, so PowerShell is your friend!

For my example, I wanted to force MFA if the request comes from a browser on the extranet. This ensures that Outlook, the Skype for Business client and mobile applications never require MFA, but any access from browsers outside of the local network are MFA secured. The claim looks like this:

Before this was placed into production, a similar claim rule was applied which limited MFA to only a particular group of users. The claim for this is shown below and the group is specified using the ObjectSID. This is useful for testing the rule out on a subset of users:

This gave us the settings we needed for compliance, and figuring out the claim rules was complicated but quite fun. I hear that all this functionality will be moving into a GUI based system in Server 2016 so that’ll be nice.

Anyway, if anybody has any particular claim types they would like for particular situations, let me know and we can try and put something together

P.S. Huge thanks to Mark Vale and his article on the same subject, it helped me find the light in a very dark tunnel!

This blog post details the User Rights Assignments required for AADSync / AADConnect and the ADFS service accounts to allow them to do their thing! These privileges may be set on the Local Security Policy (secpol.msc) or may be controlled via Group Policy, depending on how your environment is configured. If you do come across any issues which look to be permissions based, please don’t just give the service accounts Domain or Enterprise Admin privileges! The reason we have service accounts is to limit the attack surface of any given application, and using the Domain/Enterprise Admin groups makes the whole concept of service accounts redundant. Anyway….

If your User Rights Assignments are configured in the Local Security Policy, the settings will be located under:

Security Settings>Local Policies>User Rights Assignment

If your User Rights Assignments are configured in Group Policy, the settings will be located under:

If you need to add a local account to a Group Policy User Rights Assignment setting, then you will need to install the Group Policy Management Console feature on the machine which hosts the local account, and edit the group policy from there. This will allow you to resolve the local account details!

AADSync / AADConnect

If you are using AADSync, then the randomly generated AAD_xxxxxxxxx service account requires both ‘Log on as a service’ and ‘Log on as a batch job’ privileges for the machine on which AADSync is installed on.

If you are using AADConnect, then the randomly generated account mentioned above is no longer relevant (thankfully!) because it no longer exists. The synchronisation service now runs under the designated Active Directory service account, which is useful =] This account requires ‘log on as a service’, ‘log on as a batch job’ and also ‘log on locally’, although I’m not 100% sure why ‘log on locally’ is actually required.

ADFS

If ADFS is being installed, then the ADFS service account will require ‘Log on as a service’, as will the account ‘NTSERVICE\ALL SERVICES’. This last setting is done in order to allow the WID database for ADFS to work properly.

If you do not allow NTSERVICE to ‘Log on as a Service’, you may see the following error:

MSSQK$MICROSOFT##WID service was uanble to log on as NT SERVICE\MSSQL$MICROSOFT##WID

If this happens to you during the installation of ADFS, then your culprit will be the logon as a service rights!

This issue is fairly well documented, but I wanted to put it here for my own purposes:

When installing a new ADFS farm, you may find that if you reboot the ADFS server, or restart the ADFS service, it will not restart and fails with a 1297 error code. In the Event Viewer you will see an error stating that;

A privilege that the service requires to function properly does not exist in the service account configuration

This error screams of an issue with the configuration of the service account…and that’s exactly what it is. On the affected ADFS server, open the Local Security Policy console (secpol.msc) and expand the following container:

Security Settings\Local Policies\User Rights Assignment

Go into the properties of the Generate Security Audits section and add the ADFS service account into here. If the option to add an account is grayed out, then that means that a Group Policy is controlling this access list, and you will need to find and modify the appropriate GP to add the ADFS service account into the group (usually the Default Domain Policy). While you are here, ensure that the ADFS service account has ‘Log on as a Service’ privileges.

Once this is done you should be able to start the ADFS service (although if you edited Group Policy then run gpudpdate first). Hopefully this helps you before you get to the point where you make the ADFS service account a Domain Admin! Remember, this account only needs Domain User privileges and should not be put into god mode!