Latest Entries »


As a general best practice, you should simplify your site topology and site link costs as much as possible if you enable the Try Next Closest Site setting. In enterprises with many hub sites, this can simplify any plans that you make for handling situations in which clients in one site need to fail over to a domain controller in another site.

By default, the Try Next Closest Site setting is not enabled. When the setting is not enabled, DC Locator uses the following algorithm to locate a domain controller:

  • Try to find a domain controller in the same site.
  • If no domain controller is available in the same site, try to find any domain controller in the domain.

How to:



Splunk 2017 conference




Windows 2003 Supports:

  • SNMPv2x

Windows 2008 Supports:

  • SNMPv1 and SNMPv2

Windows 2012 does not Support SNMP:

  • SNMP is deprecated. Instead, use the Common Information Model (CIM), which is supported by the WS-Management web services protocol and implemented as Windows Remote Management.

Test if SNMP devices are responding correctly to SNMP queries:

This post will try to explain some relevant parameters from the ADFS side. I’m not saying the defaults aren’t good, that’s something you’ve got to decide for yourself.


WS-Fed/SAML protocol requirements: All time is UTC. ADFS will ignore system time and will use UTC.

Dates in SAML

A Security Assertion Markup Language(SAML) assertion might contain many attributes that contain dates. For example the following Conditions element of a SAML assertion has two date attributes:
<saml:Conditions NotOnOrAfter=”2013-07-29T23:49:40.051Z” NotBefore=”2013-07-29T23:39:40.051Z”>

Time in SAML elements is expressed in xs:dateTime format (xs is a XML format style). The Z at the end indicates that the Time Zone is Coordinated Universal Time (UTC) or Zulu time format. SAMLCore explicitly references “W3C XML Schema Datatypes specification [Schema2]” which in turn references ISO 8601.

Dates in OpenTokens

An OpenToken contains multiple dates. For example the following OpenToken contains three dates:


The format for OpenTokens also uses ISO 8601 which also uses UTC.
See also: Microsoft KB 884804 – How to convert UTC time to local time

WebSSOLifetime (Default 480 = 8 hours)

This parameter is server-wide. Meaning if you configure it, it’s active for all of the ADFS relying parties. Whenever a user asks a token for a given RP he will have to authenticate to the ADFS service first. Upon communicating with the ADFS service he will receive two tokens: a token which proves who he is (let’s call that the ADFS Token) and a token for the RP (let’s say the RP Token). All in all this seems very much like the TGT and TGS tickets of Kerberos.

Now the WebSSOLifetime timeout determines how long the ADFS token can be used to request new RP Tokens without having to re-authenticate. In other words a user can ask new tokens for this RP, or for other RP’s, and he will not have to prove who he is until the WebSSOLifetime expires the ADFS token.

TokenLifetime (Default 0 (which is 10 hours))

The TokeLifetime is now easy to explain. This parameter is configurable for each RP. Whenever a user receives a RP Token, it will expire at some time. At that time the user will have to go to the ADFS server again an request a new RP token. Depending on whether or not the ADFS Token is still valid or not, he will not have to re-authenticate.

One argument to lower the TokenLifetime could be that you want the claims to be updated faster. With the default whenever some of the Attribute Store info is modified, it might potentially take 10 hours before this change reaches the user in its claims.

NotBefore and NotOnOrAfter, NotBeforeSkew

Setting up federated trusts with third-party vendors to provide users with single sign on (SSO) is very common.  SAML2 is the preferred method for SSO authentication.  One issue with this method is ensuring the SAML tokens have a valid lifespan.  Basically, when does a token become valid and when is it no longer valid.  Built into the SAML specification, there is a <saml:Conditions> element, which contains two attributes; NotBefore and NotOnOrAfter.  The NotBefore attribute contains the date and time value that specifies when the assertion becomes valid.  The NotOnOrAfter attribute contains the date and time value that specifies when the SAML assertion is no longer valid.  Both must be UTC datetimes, without the time zone.  As long as the SAML token is being used between the NotBefore and NotOnOrAfter times the assertion will be valid.

But what happens when the IdP server time and the third-party server times are off by a few seconds, or even a couple of minutes?  Simple, authentication may fail because the third-party server may see the SAML as not yet valid.

Luckily, ADFS 3 (Windows Server 2012 R2) offers a simple solution.  A simple time skew value can be added to the relying party on the ADFS server.  This property is called NotBeforeSkew.  It contains the number of minutes to adjust the NotBefore value by.  Setting the NotBeforeSkew to a value of 5 will result in a NotBefore of -5 minutes.

The following PowerShell command can be used to set the NotBeforeSkew value.

Set-ADFSRelyingPartyTrust -TargetIdentifier "<replying party identifier>" -NotBeforeSkew 5


ADFS Backup Restore tool

ADFS Rapid restore tool:

– download it from Microsoft Connect. 

With ADFS Rapid Restore Tool, backup and restore your ADFS farm easily in seconds…


To backup your ADFS farm, use the command listed below with the following switches:

  • BackupDKM – Backs up the Active Directory DKM container that contains the AD FS keys in the default configuration (automatically generated token signing and decrypting certificates).
  • StorageType – The type of storage:“FileSystem” -stores backup it in a folder locally or in the network.“Azure”-stores backup in the Azure Storage Container (Azure Storage Credentials should be passed to the cmdlet). The storage credentials contains the account name and key,a container name must also be passed in,if the container doesn’t exist, it is created during the backup.
  • EncryptionPassword – The password that is going to be used to encrypt all the backed up files before storing it
  • AzureConnectionCredentials – The account name and key for the Azure storage account
  • AzureStorageContainer – The storage container where the backup will be stored in Azure
  • StoragePath – The location the backups will be stored in
  • ServiceAccountCredential – specifies the service account being used for the ADFS Service running currently. This parameter is only needed if the user would like to backup the DKM and is not domain admin.
  • BackupComment <string[]> – An informational string about the backup that will be displayed during the restore, similar to the concept of Hyper-V checkpoint naming. The default is an empty string


import-module ‘C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll’

Backup-ADFS -StorageType “FileSystem” -StoragePath “d:\Scripts\ADFS Backups\” -EncryptionPassword “mypwd” -BackupComment “ADFS” -BackupDKM

In the same way, the restore process is also very easy to achieve with the following switches:

StorageType – same as for backup (“FileSystem” and “Azure”)

  • DecryptionPassword – The password that was used to encrypt all the backed up files
  • AzureConnectionCredentials – The account name and key for the Azure storage account
  • AzureStorageContainer – The storage container where the backup will be stored in Azure
  • StoragePath – The location the backups will be stored in
  • ADFSName < string > – The name of the federation that was backed up and is going to be restored.
  • ServiceAccountCredential < pscredential > – specifies the service account that will be used for the new ADFS Service being restored
  • GroupServiceAccountIdentifier – The GMSA that the user wants to use for the new ADFS Service being restored. By default, if neither is provided then the backed up account name is used if it was GMSA, else the user is prompted to put in a service account
  • DBConnectionString – If the user would like to use a different DB for the restore, then they should pass the SQL Connection String or type in WID for WID.
  • Force – Skip the prompts that the tool might have once the backup is chosen
  • RestoreDKM – Restore the DKM Container to the AD, should be set if going to a new AD and the DKM was backed up initially.

Note that you must specify the database engine type used with the ADFS farm by using the -DBConnectionString parameter as follow:

To restore your ADFS farm when using WID Database or SQL Server, use respectively the following paramters:

import-module ‘C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll’

Restore-ADFS -StorageType “FileSystem” -StoragePath “d:\Scripts\ADFS Backups” -DecryptionPassword “mypwd” -RestoreDKM

DBConnectionString “WID” 

Restore-ADFS -StorageType “FileSystem” -StoragePath “d:\Scripts\ADFS Backups” -DecryptionPassword “mypwd” -RestoreDKM 

-DBConnectionString “Data Source=SQLServer\SQLINSTANCE; Integrated Security=True”

During the restore process, note that the ADFS Rapid Restore Tool proposes to the administrator to specify which backup to restore  – based on date and time.

As you can see, at this point, it’s almost done because after the restore operation, the ADFS service is not yet operational and running!

What’s new in ADFS 2016?

  • Eliminate Passwords from the Extranet
  • Sign in with Azure Multi-factor Authentication
  • Password-less Access from Compliant Devices
  • Sign in with Microsoft Passport
  • Secure Access to Applications
  • Better Sign in experience
  • Manageability and Operational Enhancements

You can upgrade an AD FS 2012 R2 farm using the “mixed farm” process described here. It works for WID or SQL farms, though the document shows only the WID scenario. Also another upgrade procedure:

  1. Active Directory schema update using ‘ADPrep’ with the Windows Server 2016 additions
  2. Build Windows Server 2016 servers with ADFS and install into the existing farm and add the servers to the Azure load balancer
  3. Promote one of the ADFS 2016 servers as “primary” of the farm, and point all other secondary servers to the new “primary”
  4. Build Windows Server 2016 servers with WAP and add the servers to the Azure load balancer
  5. Remove the WAP 2012 servers from the Azure load balancer
  6. Remove the ADFSv3 servers from the Azure load balancer
  7. Raise the Farm Behavior Level feature (FBL) to ‘2016’
  8. Remove the WAP servers from the cluster
  9. Upgrade the WebApplicationProxyConfiguration version to ‘2016’
  10. Configure ADFS 2016 to support Azure MFA and complete remaining configuration

Other links:

ADFS 2016 operations

ADFS 2016 deployment

ADFS 2016 design

IT Self-trainings

IT pro TV:

Microsoft virtual academy:

Microsoft channel9:


Concernant le déploiement des binaires :

Concernant la juxtaposition Project/Visio avec Office 365 :