Updating expired certificates in ADFS 2016

Today I had a call from a customer because they had expired certificates in their ADFS farm. Once I acceded to the farm, I realized that the expired certificates were the token signing and token decrypting certificates.

So, the first thing that I did, was to extend the certificate window expiration:

Set-ADFSProperties -CertificateDuration 36500

Then, update the expired certificates

Update-ADFSCertificate -CertificateType Token-Signing -Urgent

Update-ADFSCertificate -CertificateType Token-Decrypting -Urgent

And finally to restore the Office365 Enpoint, the following commands:

$cred=Get-Credential

Connect-MsolService –Credential $cred

Update-MSOLFederatedDomain –DomainName “DomainName” -SupportMultipleDomain

*In my case I needed to set this parameter

And that’s all!

Till next time

Advertisement

Migrating from ADFS 2012R2 to ADFS 2016

I recently went through the effort to migrate a Windows Server 2012 R2 AD FS farm to a Windows Server 2016 AD FS farm, the main point here that they want to maintain IP addresses and DNS.

First of all, there is something in Windows Server 2016 ADFS called  Farm Behavior Level (FBL)  feature (FBL), which determines the features that the AD FS farm can use.

The great thing is that you can add an ADFS 2016 Server to a w2012R2 farm without changing the FBL of the farm, but take into account that the new features won’t be available until you raise the FBL.

Before raising the FBL, you must know that it is necessary to update the AD Schema, at least to level 85, so it involves to deploy a W2016 DC into your network. More info at: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/overview/ad-fs-2016-requirements

Once you have done this, is it possible to change the FBL, but you will need to follow the following steps:

• Set the new ADFS 2016 server as primary ADFS server: Set-AdfsSyncProperties -Role “PrimaryComputer”
• On the old primary ADFS 3.0 server run the following command: Set-AdfsSyncProperties -PrimaryComputerName “newprimarycomputername” -Role “SecondaryComputer”
• On the other secondary ADFS 3.0 servers run the following command: Set-AdfsSyncProperties -PrimaryComputerName “newprimarycomputername”
• Upgrade the ADFS 2016 fam behaviour level: Invoke-AdfsFarmBehaviorLevelRaise

Finally, you will to test and validate your new ADFS farm, remember to upgrade your WAP servers as well, but this process it is pretty straightforward

Auditing in ADFS 2016

By default, AD FS in Windows Server 2016 has a basic level of auditing enabled. With basic auditing, administrators will only be able to see up to five events for a single request. But we can  raise the auditing level using the PowerShell cmdlet Set-AdfsProperties -AuditLevel.

The following table identifies the available auditing levels.

Audit Level	PowerShell syntax	Description
None	Set-AdfsProperties – AuditLevel None	Auditing is disabled and no events will be logged.
Basic (Default)	Set-AdfsProperties – AuditLevel Basic	No more than 5 events will be logged for a single request
Verbose	Set-AdfsProperties – AuditLevel Verbose	All events will be logged. This will log a significant amount of information per request.

If you need to check the current auditing level, you can use the PowerShell cmdlet Get-dfsProperties.

ADFS: Enable SSO for Edge and Chrome

This is some very common and easy to solve, so in order to get browser to support SSO on the Intranet to ADFS is it necessary to include some useragent.

In case you have Chrome version 50 or lower you will need to disable the property “ExtendedProtectionTokenCheck”

Set-ADFSProperties –ExtendedProtectionTokenCheck None

But I hope that you’re keeping up to date all the versions in your system, so continue reading 🙂

With the following command you will be able to get all the properties that you currently have in your ADFS farm:

[System.Collections.ArrayList]$UserAgents = Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents

Execute the following command to inject the user agent into a temporary array of user agents already added to ADFS.

$UserAgents.Add(“Mozilla/5.0”,”Edge/12″)

Execute the following command to commit the change.

Set-ADFSProperties -WIASupportedUserAgents $UserAgents

Restart the ADFS service in all servers of the farm, and you can check your changes with the following command:

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

That’s all folks!

 

Configuring Azure MFA in ADFS: Service Principal was not found

Hi All,

Today I’m back with ADFS, the other day I needed to configure ADFS with Azure MFA for a client. In this case, first I configured the ADFS farm (in my case with WS2016), and then I was ready to configure Azure MFA in the Authentication methods for the Intranet and Extranet.

Why? Because it was a requirement for the project that all internal users use MFA in order to authenticate to O365. Thus we can integrate this with ADFS in a very simple (but tricky) steps. As you know, if you have E1 or E3 licenses, you can use Azure MFA by default, is it not necessary to purchase extra licenses in order to use this service. **First point to take into account

For the record, you will need to use the Connect-MSolService cmdlet, so be sure that you have installed the PowerShell modules in your server

Install-module MSOnline
Install-module AzureAD

Once you have installed this, you need to execute the following commands:

$tenantID = “yourtenant.onmicrosoft.com”
$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID $tenantID

Connect-MsolService
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64
Set-AdfsAzureMfaTenant -TenantId $tenantID -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

You can check the info in the following article: https://docs.microsoft.com/es-es/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa

But in my case, every time I was executing the command New-MSOLServicePrincipalCredential, I was receiving an error saying: “Principal Service was not found” I double checked if I was Global ADmin in the O365 and Azure subscription and I was!! So… what the hell means that error??

It means that you don’t have registered the SPN for Azure MFA, and to solve this it is very simple, you can purchase a trial of Azure MFA (P1, P2, EMS, o whatever plan where Azure MFA is included) and assign a license to one user, for example in my case, I assigned the license to the test users. It seems that you will not see “Azure Multi-Factor Auth Client” in the list of MSOL Service Principals until you have at least one account with an MFA license on your tenant.

After doing this, I needed to wait a couple of minutes and then I executed again the PS commands that I showed before… and bang!! I was able to register the Azure MFA as authentication method in ADFS Server.

I think that the short history is that using the new ADFS adapter requires MFA licenses. It doesn’t work with an MFA Provider, but MFA licenses can be purchased standalone or the ones included in Azure AD Premium and EMS

That’s all for today!

ADFS Changing Hash algorithm for O365

By default ADFS sign tokens on Azure AD to reassute that is not possible to modify o alter them, as probably you know, everything is related with security, in this case those signs are encrypted with SHA1 or SHA256.

By default, when you deploy an ADFS service and you federate with O365, the RPT created is done with SHA1, but if we wnat to increase security in this RPT, we can change it to SHA256.

The only thing that we have to do is to enter to the ADFS console, go to the RPT in question, and then change the secure hash algorithm.

That’s all!

Back to ADFS Certificates

Hi there!

ADFS certificates? Yes! They come back to me as little nightmare xD, but in the end, this time was pretty simple to solve it.

The problem begun with a client call that I planned to visit the same day (for other reasons), and he was in panic because the certificates associated with the CRM and ADFS needs to be updated, since the day after will expire.

At the beginning I though, “I don’t have any idea about CRM and how to update the certificates”, but having a technical background I decided to tell him that after the meeting we could have a look to the CRM and the ADFS farm to see what was happening.

Once I finished the meeting with him, I meet with the person in charge of updating the certificates, he explained me how he updated the certificates in the CRM, but he still has a problem with the certificates in the ADFS farm, for me it was like light in the darkness, I don’t need to deal with the CRM, only with ADFS!! 1 point!

Looking to the ADFS farm, the first thing that I realized it was that he updated the decrypting and signing certificates, but the service communications shows a message saying that “It is not possible to find the certificate”. Weird… the client told me that he imports the certificates in the personal Store, so the certificates exist.

If you tried to associate a new certificate with the button “Set service communications certificate”, it fires an error in the ADFS console, but it doesn’t write anything in the event viewer. I started to check in the IIS (it was a 2.0 ADFS) the certificates, I realized that in the binding, the certificate was not associated, I associated it, okay.

Come back to the ADFS console, and try to re-associate the certificate, no luck.

I was pretty sure, that the problem was with the certificate associated, so I starts to look into my PowerShells, one PowerShell to reassociate the CS certificate by scripting, since the interface does not work. But by the time, I asked to the client if he still conserves the old certificate that he delete it, he say yes, and I asked him to reimport it again to the store.

Once the certificate was imported again, I refresh the ADFS farm… and bang!! The CS shows the old certificate, great, then my following action was to try to set the set service communication certificate, and bang! It shows the dialog where is it possible to see the old certificate and the new one, I selected the new one and finally I restarted the ADFS service.

I tested with the CRM, and it was possible to see that it connects with the new certificate 😊. So… what I learned from this experience? Never delete a certificate without first renewing it and test that everything is okay.

By the way, I found the PS to set the CS certificate, but it was not necessary to execute it:

Set-AdfsSslCertificate –Thumbprint <ThumbprintCertificate>

Set-WebApplicationProxySslCertificate –Thumbprint <ThumbprintCertificate>

How to connect to Windows Internal Database (WID) with SQL Server Management Studio

The Windows Internal Database (WID) is used by the following Windows server components:

• Windows Server Update Services (WSUS)
• Active Directory Federation Services (AD FS)
• Active Directory Rights Management Services (AD RMS)
• Windows System Resource Manager (WSRM)

For Windows Server 2008 R2 and Windows Server 2008, you can use the following named pipes (NP) string:

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

On Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016 you must use a different np connection string:

\\.\pipe\MICROSOFT##WID\tsql\query

ADFS 4.0 idpinitiatedsignon Error

Hi all,

The other day I was creating an ADFS lab in order to test some features and configurations, as you will probably know, a quick way to test an ADFS deployment is to access the idpinitiatedsignon sign page.

After I deployed my ADFS farm, I tried to access and I received the following error message: “The resource you are trying to access is not available. Contact your administrator for more information.”

At the beginning it was annoying, because I was thinking that I did someone incorrectly, so I spend some time thinking about what I did wrong, I checked the event log and I saw the following:

Description:
Encountered error during federation passive request.

Additional Data

Protocol Name:
Relying Party:
Exception details:
Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

So, indeed what it is saying is that the idpinitiatedsignon property is disabled. So, to check if it is this, you can execute the following PS command in the ADFS farm:

Get-AdfsProperties | fl *idpinitiatedsignon*

As you can see in the picture, it was disabled, so in order to solve this problem, just run the following command:

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

After that, all my problems were solved 😊

Enable ADFS automatic certificate rollover

Hi!

After the summer holidays, I realised that the token decripting and token signing certificates from the ADFS, were about to expire. I tried to execute the following command to update immediately the certificates:

Update-ADFSCertificate -Urgent

but I received the following message error:

To enable the ADFS automatic certificate rollover, use the below Powershell script command, this will help if you want to add a token signing certificate when the automatic certificate rollover is enabled.

Set-ADFSProperties -Autocertificaterollover $true

After doing that, I was able to update the ADFS certificates from the certificate store.

Hope it helps!