Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2017-06-23) Adding A Link To The SSPR Page In The ADFS FBA Page

Posted by Jorge on 2017-06-23


When users use Windows Integrated Authentication against ADFS through their Windows desktop/laptop the users are authenticated based upon the credentials they used to logon with onto that Windows desktop.laptop. If those users needed to reset their password or unlock their account, a link would need to be provided within the logon screen to point to the SSPR page or users would need to use some kind of kiosk PC.

However, when hitting the Forms Based Authentication page within ADFS, it would be nice if you could display a link on that same page if users needed to reset their password or unlock their account when for example on a mobile device. Something similar to the following:

image 

Figure 1: A Link To The SSPR Page On The FBA Page

If you want to do this, you can use the following steps

[Step 1]

Clone the current active ADFS web theme to a new ADFS web theme

First determine the current web theme

Get-ADFSWebConfig

Clone the current active web theme to a new web theme

New-AdfsWebTheme -Name <New Web Theme Name> -SourceName <Active Web Theme Name>

[Step 2]

Export the cloned web theme to a folder on the file system

Export-AdfsWebTheme -Name <New Web Theme Name> -DirectoryPath <Some Folder On The File System>

[Step 3]

Edit the file “onload.js” in the folder “<Some Folder On The File System>\Script” and add the following piece of code to the end of the file to show the link to the SSPR page in AAD on the FBA page (NOTE: you can use any other SSPR page if you want, such as the FIM/MIM SSPR page)

// Add link for password reset, if we find the forms authentication element in the page
var formsAuthArea = document.getElementById("formsAuthenticationArea");
if (formsAuthArea) {
    //Create the hyperlink
    var pwdResetLink = document.createElement(‘a’);
    var linkText = document.createTextNode("Click Here For Password Reset Or Account Unlock");
    pwdResetLink.appendChild(linkText);
    pwdResetLink.title = "Click Here For Password Reset Or Account Unlock";
    pwdResetLink.href = "
";’>";’>https://passwordreset.microsoftonline.com/?whr=<Your Domain In AAD>";
    pwdResetLink.target = "_blank";
    document.body.appendChild(pwdResetLink);

    //append to the authArea
    var authNArea = document.getElementById("authArea");
    authNArea.appendChild(pwdResetLink);
}

[Step 4]

Import the new edited “onload.js” file

Set-AdfsWebTheme -TargetName <New Web Theme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Some Folder On The File System>\script\onload.js"}

[Step 5]

Activate the new web theme

Set-AdfsWebConfig -ActiveThemeName <New Web Theme Name>

Now access an application and make sure to use the FBA page. The FBA page is used when coming from a mobile device on an external network or when not using WIA

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Forefront Identity Manager (FIM) Portal, Forms Based AuthN, Self Service Password Reset, Self-Service Password Reset, Windows Azure Active Directory | Leave a Comment »

(2017-06-19) Azure AD Connect Health For Sync To The Rescue

Posted by Jorge on 2017-06-19


I was playing around with some Azure AD (AAD) features and I required a new synched account in AAD. So I picked one of my existing accounts in the on-premises AD and added the user account to the groups that allowed it to sync to Azure AD, assign it a license for O365, assign a license for EMS and allow it to use SSPR. Instead of waiting for the next sync cycle I decided to force a delta sync within AAD Connect. So far so good. While AAD Connect was synching I decided to prepare some other things.

To my surprise I saw the following error in AAD Connect

image

Figure 1: Error In AAD Connect About “AttributeValueMustBeUnique”

Clicking on [Detail] I saw the following details regarding the error

image

Figure 2: Error Details In AAD Connect About “AttributeValueMustBeUnique”

ERROR = AttributeValueMustBeUnique
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:John.Doe@XXXXX;]. Correct or remove the duplicate values in your local directory. Please refer to
http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.
Tracking Id: xxxxxxxxxxxxxxxxxxxxxxxxxx
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["xxxxxxxxxxxxxxxxxxxxxxxxx"]},{"Key":"ObjectIdInConflict","Value":["yyyyyyyyyyyyyyyyyyyyyy"]},{"Key":"AttributeConflictName","Value":["ProxyAddresses"]},{"Key":"AttributeConflictValues","Value":["SMTP:John.Doe@XXXXX"]}]

This is basically saying there is another object in AAD with the same value of "SMTP:John.Doe@XXXXX" in the proxyAddresses attribute

Now that was weird because the object with UPN ‘John.Doe@XXXXX’ was never synched to AAD as a user. To be sure I checked if there already was a user with the same UPN and/or proxyAddresses. As I expected there was none. I also knew for sure there was no conflicting object in the on-premises AD. Nevertheless I checked it with ADFIND (instead of PowerShell because hadn’t used for quite some time!). And again as expected there was none! So what the heck is going on!?

First I will tell you what was wrong and why, and after that I will guide you through troubleshooting

At this point in time I’m always using AAD Connect to sync stuff from AD to AAD. I also have a MIM Infrastructure using the AAD connector that also syncs stuff from AD to AAD and more specifically users, groups and contacts. However I had not used that for quite some time. What I had forgotten was that in the past I synched my mailbox enabled user accounts to AAD (Office 365) as contacts. So almost all on-premises users exist as contacts in AAD.

Definition of the issue:

The error in figure 2 is misleading as it is telling me to check my on-premises AD to resolve the conflict, but there is NO conflict in my on-premises AD!

Just to be sure I used:

  • ADFIND/PowerShell to query for any object with the same UPN value or the same proxyAddress value – Only 1 object was returned which was expected
  • IDFIX to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected
  • Directory Synchronization Troubleshooter to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected

Now it was time to check AAD. It had to be in AAD somewhere, but what was causing it!? I was looking at all troubleshooting capabilities.

I found the following blog posts that ONLY focus on user accounts in AAD

Looking at the error in figure 2:

  • “ObjectId” contains the objectID of the object I was trying to sync to AAD
  • “ObjectIdInConflict” contains the objectID of the object already in AAD with which the conflict was being caused

Therefore I needed to query AAD using the objectID in “ObjectIdInConflict”. I decided to use the CMDlets in the MSONLINE module

To look for users in AAD with that same objectID, I executed:

Get-MsolUser -ObjectId <objectid value in “ObjectIdInConflict”>

No result

To look for groups in AAD with that same objectID, I executed:

Get-MsolGroup -ObjectId <objectid value in “ObjectIdInConflict”>

No result

I suddenly remembered about my MIM infrastructure and what it was synching, so I decided to also execute:

Get-MsolContact -ObjectId <objectid value in “ObjectIdInConflict”>

Bingo! One object was returned! Yeah!

Now I do not have many objects. Howeverm if you do have many object, this might take quite some time as unfortunately the MSONLINE module does not have a CMDlet like ‘Get-MsolObject’. However, the AzureAD module does have such a CMDlet that allows you to search across object types, being:

Get-AzureADObjectByObjectId -ObjectIds <objectid value in “ObjectIdInConflict”>

Again, Bingo! One object was returned! Yeah!

I also received the following e-mail telling me about the conflict. To be honest, the mail is not really helpful from an informational perspective. It is however from a warning perspective. With the latter I mean it triggers me to go look in Azure AD Connect Health, which will tell me what is wrong and why.

image

Figure 3: Mail From AAD Telling Me About the Conflict Error

Another option for troubleshooting this is Azure AD Connect Health for Sync. Trust me when I say that Azure AD Connect Health tells what is wrong and why. It showed me the sync error including all the specifics around the error in one view. Really really helpful! Let’s have a look at this!

Go to the Azure AD Portal (https://portal.azure.com/) and then go to the Azure AD Connect Health blade. In my case I have Azure AD Connect Health for Sync, ADFS and AD. So should you!. Make it easy on yourself!

Although Azure AD Connect Sync tile so as healthy, to its left, does tell you there is a sync error. Click on that tile.

image

Figure 4: Azure AD Connect Health In The Azure AD Portal

A new window opens with all the sync errors by type. In this case it is about the “Duplicate Attribute” issue. I clicked on that tile

image

Figure 5: Azure AD Connect Health For Sync With Errors By Type

A new window opens with all the sync errors about “Duplicate Attributes”. In my case I had and saw an error about a duplicate value in the proxyAddresses attribute. I clicked on the listed object.

image

Figure 6: Azure AD Connect Health For Sync With A “Duplicate Attribute” Error For An Object

A new window opens with all the details about the “Duplicate Attribute” conflict and the objects involved. At the bottom you can see the conflicting attribute and the conflicting value. Now I know I have to get rid of the contact object to make it possible for the user account in AD to get a corresponding user account in AAD.

image

Figure 7: Azure AD Connect Health For Sync With “Duplicate Attribute” Error Details

BINGO!!! Smile

Now my suggestion for this is:

  • Make sure to get Azure AD Connect Health up and running
  • As soon as you see an error in AAD Connect (figure 1 and 2) or receive the e-mail (figure 3) about it, make sure to read it carefully. At this point in time I would say to go right away to the Azure AD Connect Health blade in the Azure AD Portal and check there what could be wrong. It is very likely it will tell you what is wrong and why!

Additional information:

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Azure AD Connect Health, PowerShell, Windows Azure Active Directory | Leave a Comment »

(2017-06-15) Displaying The Welcome Message On The MFA Page In ADFS 2016

Posted by Jorge on 2017-06-15


In ADFS 2012 R2 when hitting the MFA page a welcome message was displayed with an explanation as shown in figure 1 below

image

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

Looking at the default behavior in ADFS 2016 you will get the following instead

image

Figure 2: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

There is no welcome message anymore and the identity value is now located in the explanation at the end.

If you want to revert back to the ADFS 2012 R2 behavior you can do the following:

[Step 1]

Clone the current active ADFS web theme to a new ADFS web theme

First determine the current web theme

Get-ADFSWebConfig

Clone the current active web theme to a new web theme

New-AdfsWebTheme -Name <New Web Theme Name> -SourceName <Active Web Theme Name>

[Step 2]

Export the cloned web theme to a folder on the file system

Export-AdfsWebTheme -Name <New Web Theme Name> -DirectoryPath <Some Folder On The File System>

[Step 3]

Edit the file “onload.js” in the folder “<Some Folder On The File System>\Script” and add the following piece of code to the end of the file to show the welcome message again

// Check if we are in the auth area
var authNArea = document.getElementById("authArea");
if (authNArea) {
    // if mfaGreeting element is present, modify its properties.
    var mfaGreeting = document.getElementById("mfaGreeting");
    if (mfaGreeting) {
        mfaGreeting.className = "fieldMargin bigText";
    }
}

[Step 4]

Import the new edited “onload.js” file

Set-AdfsWebTheme -TargetName <New Web Theme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Some Folder On The File System>\script\onload.js"}

[Step 5]

Activate the new web theme

Set-AdfsWebConfig -ActiveThemeName <New Web Theme Name>

[Step 6]

Reconfigure the explanation text if required

Set-AdfsGlobalWebContent -SignInPageAdditionalAuthenticationDescriptionText "For security reasons, we require additional information to verify your account"

Now access an application through ADFS for which MFA is required

If you did display the Welcome message and did not revert back to the explanation as shown in the ADFS 2012 R2 you would see something similar to

image

Figure 3: Customized MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Claim Types, onload.js | Leave a Comment »

(2017-06-12) Changing The Identity Type Displayed On The MFA Page In ADFS

Posted by Jorge on 2017-06-12


By default when you hit the MFA page in ADFS 2012 R2, the identity type displayed is similar to DOMAIN\SAMACCOUNTNAME as you can see in figure 1 below. The MFA page in ADFS 2012 R2 by default uses the value from the name claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”) to display that same value in the MFA page in ADFS 2012 R2.

The name claim type is configured by default in an Acceptance Transform Rule on the “Active Directory” CP trust, and it is most likely read from the “msDS-PrincipalName” attribute in AD.

The Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type may be similar to

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c);

image

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

However, with all the cloud development going on and everything focusing on the mail address of a user instead, you may want to display the mail address of the user instead as displayed in figure 2 below.

To make this change you need to delete the default Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type and create a new rule where you will flow the value of the mail claim value (MAIL@ADDRESS.COM) into the name claim type. The new Acceptance Transform Rule on the “Active Directory” CP trust would look like:

@RuleTemplate = "MapClaims"
@RuleName = "E-mail Address To Name"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

image

Figure 2: MFA Page In ADFS 2012 R2 With The Custom Value For The Name Claim Type

Is there a catch to this? Yes there is, or better yes there are!

[Catch 1]

By default the e-mail address is NOT extracted from AD by ADFS! Because of that you need to create your own Acceptance Transform Rule where you do that. The Acceptance Transform Rule you need at least is or looks similar to:

@RuleTemplate = "LdapClaims"
@RuleName = "E-mail Address"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&quot;), query = ";mail;{0}", param = c.Value);

Because the name claim type depends on this Acceptance Transform Rule, this Acceptance Transform Rule for the mail claim type must be processed before the Acceptance Transform Rule for the name claim type

[Catch 2]

Some applications connected to ADFS may expect to receive a name claim value that looks like DOMAIN\SAMACCOUNTNAME instead of MAIL@ADDRESS.COM. By implementing the new Acceptance Transform Rule for the name claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the RP trust of the application that needs the name claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"%5D => issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Windows Account Name To Name"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

[Catch 3]

By default when you hit the MFA page in ADFS 2016, the identity type displayed is similar to UPN@ADDRESS.COM as you can see in figure 1 below. The MFA page in ADFS 2016 by default uses the value from the upn claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”) to display that same value in the MFA page in ADFS 2016. However, if there is no value for the upn claim, it will fall back to the value of the name claim. Unless you have removed it, by default ADFS has an Acceptance Transform Rule on the “Active Directory” CP trust for the upn claim type. And if you look carefully, the text also changed (compare figure 1 and figure 3).

As you can see in figure 3, it now really shows my upn (jorge@iamtec.net) whereas mail e-mail address uses a different suffix (jorge@iamtec.nl). With the use of Azure AD, the federated/managed domain in AAD is iamtec.nl and not iamtec.net.

image

Figure 3: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

To be able to logon with the mail address I have 2 options, either update the userPrincipalName value to match the mail address value in AD or keep it as is and use the alternate logon ID feature in ADFS to target the mail address field in AD. If you choose the first option the value in the MFA page is also updated automatically and you do not need to update Acceptance Transform Rules. If you choose the second option you may need to delete the default Acceptance Transform Rule for the upn claim type and replace it with the following Acceptance Transform Rule:

@RuleTemplate = "MapClaims"
@RuleName = "E-Mail Address To UPN"

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

This new Acceptance Transform Rule for the upn claim type would result in the following for on the MFA page in ADFS 2016

image

Figure 4: MFA Page In ADFS 2016 With The Custom Value For The UPN Claim Type

Is there a catch to the catch? Unfortunately there is! As mentioned earlier for the name claim type, the same would apply to the upn clam type. Some applications connected to ADFS may expect to receive a upn claim value that looks like UPN@ADDRESS.COM instead of MAIL@ADDRESS.COM. By implementing a new Acceptance Transform Rule for the upn claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the “Active Directory” CP trust and implement an Acceptance Transform Rule that is similar to or looks like:

@RuleTemplate = "MapClaims"
@RuleName = "Original UPN To Custom UPN Claim"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(Type = "
http://temp.org/identity/claims/orgUPN&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

…and you would need reconfigure the RP trust of the application that needs the original upn claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Custom UPN Claim To Original UPN"
c:[Type == "http://temp.org/identity/claims/orgUPN""http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Claim Types, Claims, Claims Rule Language, Federation Trusts | Leave a Comment »

(2017-06-08) WHOAMI, The PowerShell Way

Posted by Jorge on 2017-06-08


Many of you probably know the command:

WHOAMI /USER /GROUPS

image

Figure 1: Executing WHOAMI

Every wanted to do the same in PowerShell?

[Security.Principal.WindowsIdentity]::GetCurrent())

image

Figure 2: Executing WHOAMI The PowerShell Equivalent

Although it gives you the required information, it still does not list the groups in a nice way. So let’s try that!

Unfortunately not a on-liner, but rather 2 lines of code Smile

$tableLayout = @{Expression={((New-Object System.Security.Principal.SecurityIdentifier($_.Value)).Translate([System.Security.Principal.NTAccount])).Value};Label="Group Name";Width=40},@{Expression={$_.Value};Label="Group SID";Width=45},@{Expression={$_.Type};Label="Group Type";Width=75}

([Security.Principal.WindowsIdentity]::GetCurrent()).Claims | FT $tableLayout

image

Figure 3: List Of Group Names, Group SIDs And Group Types From The Access Token

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in PowerShell, Tooling/Scripting | Leave a Comment »

(2017-06-04) User Verification Feature For FIM 2012 R2 And MIM 2016 (SP1)

Posted by Jorge on 2017-06-04


Ryan Newington released a new add-on for the FIM/MIM Portal some time ago. This add-on allows for the service desk to easily verify the identity of a person calling the service desk. At a high level, the user tells the service desk his/her account name which is looked up by the service desk. The service desk then generates a one-time code which is send through SMS to the previously registered mobile number of the calling user. The user receives the one-time code on his/her mobile phone through SMS and tells the service desk the one-time code that was received. If there is a match the service desk has successfully verified the identity of the calling user.

If the users are already registered for SMS-based SSPR, then this add-on is ready to use. You just need to install it and make it accessible through the user RCDC.

In my case I have adjusted the user view/edit RCDC to include the “Verify This User Using An SMS Token” link on the General TAB

image

Figure 1: The “Verify This User Using An SMS Token” Link On The General TAB Of The User Account Requiring Identification

After clicking on that link, the screen as shown in figure 2 opens where it presents some details of the user and a button [Send Code] to generate a one-time code and send it to the registered mobile number.

image

Figure 2: The Add-On In Action And Ready To Generate And Send A One-Time Code To The User

After clicking the [Send Code] button the generated one-time code is displayed as shown to the service desk in figure 3 and also send to the registered mobile phone number of the user

image

Figure 3: The Add-In In Action After Generating And Sending A One-Time Code To The User

If needed the service desk can send a new code or close the window.

The user receives the one-time code through SMS and tells the service the code to verify his/her identity

SNAGHTML3e901ed4

Figure 4: The One-Time Code Received By The User

This is so simple and yet so powerful to help those people calling the service desk for which their identity needs to be verified.

More details in the following blog post: http://blog.lithiumblue.com/2017/02/user-verification-add-on-for-fimmim.html

FIM/MIM add-on available through: https://github.com/lithnet/resourcemanagement-ui-userverification

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Forefront Identity Manager (FIM) Portal, User Verification | Leave a Comment »

(2017-05-31) FIM Calendar Has Been Updated For MIM 2016 SP1

Posted by Jorge on 2017-05-31


In the past “https://github.com/pieceofsummer” provided the FIM calendar on github for FIM 2010 (R2). With the release of MIM 2016 (SP1), “https://github.com/ryannewington” updated the FIM Calendar to also work with MIM 2016 (SP1).

image

Figure 1: The FIM Calendar Updated For MIM 2016 (SP1)

Just follow the instructions in Ryan’s Github page for the FIM Calendar and it will work for you!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Calendar, Forefront Identity Manager (FIM) Portal, RCDC | Leave a Comment »

(2017-05-27) Real Required Permissions For Password Change, Password Reset And Account Unlock Through Azure AD

Posted by Jorge on 2017-05-27


When deploying Azure AD Self-Service Password/Account Management you need to configure stuff in both Azure AD and the on-premises AD. The “what” and the “how” can be found through Azure AD self-service password reset for the IT professional.

In the on-premises AD you need to assign a number of permissions to the account for the connector/MA that services that specific AD. You will need to do this for every AD forest being serviced by AAD Connect. For every AD forest you need to determine the scope of management being either at domain level of OU level. Nevertheless, the following actions are supported by Azure AD Self-Service Password/Account Management and according to Microsoft the corresponding permissions need to be assigned to the connector/MA account (as listed here):

  • Account Unlock
    • Requires at least the Allow:Write permission for the lockoutTime  attribute on the user account
  • Password Reset
    • Requires at least the Allow:Write permission for the pwdLastSet attribute on the targeted user account
    • Requires at least the Allow:Reset Password Control Access Right (CAR) on the targeted user account
  • Password Change
    • Requires at least the Allow:Change Password Control Access Right (CAR) on the targeted user account

The permissions can be configured through the GUI in ADUC/ADAC or through DSACLS. For regular accounts the permissions need to be assigned at container level (domain or specific OUs) and must be inherited by user objects.

The “Allow:Write permission for the lockoutTime  attribute on the user account” for regular accounts can be configured through:

DSACLS "<DN of OU>" /G "<AD Group For Account Unlock>:WP;lockoutTime;user" /I:S

The “Allow:Write permission for the pwdLastSet attribute on the targeted user account” for regular accounts can be configured through:

DSACLS "<DN of OU>" /G "<AD Group For Password Reset>:WP;pwdLastSet;user" /I:S

The “Allow:Reset Password Control Access Right (CAR) on the targeted user account” for regular accounts can be configured through:

DSACLS "<DN of OU>" /G "<AD Group For Password Reset>:CA;Reset Password;user" /I:S

The “Allow:Change Password Control Access Right (CAR) on the targeted user account” for regular accounts can be configured through:

….does NOT need to be configured at all as the password change action always occurs under the context of the account for which the password is being changed. For that to be possible, AD already has the needed permissions in place for this to be possible as shown below!

image

Figure 1: The “Allow:Change Password” Permission Already Assigned By Default To The EVERYONE And SELF Security Principals

Therefore: There is NO NEED to specifically assign “Allow:Change Password Control Access Right (CAR) on the targeted user account” for the connector/MA account. It will work perfectly without it!

The exact same permissions are required on “protected” accounts. However, the permissions for those accounts need to be assigned through the adminSDHolder object. The permissions can be configured through the GUI in ADUC/ADAC or through DSACLS.

The “Allow:Write permission for the lockoutTime  attribute on the user account” for protected accounts can be configured through:

DSACLS "CN=AdminSDHolder,CN=System,<DN Of Domain>" /G "<AD Group For Account Unlock>:WP;lockoutTime;user"

The “Allow:Write permission for the pwdLastSet attribute on the targeted user account” for protected accounts can be configured through:

DSACLS "CN=AdminSDHolder,CN=System,<DN Of Domain>" /G "<AD Group For Password Reset>:WP;pwdLastSet;user"

The “Allow:Reset Password Control Access Right (CAR) on the targeted user account” for protected accounts can be configured through:

DSACLS "CN=AdminSDHolder,CN=System,<DN Of Domain>" /G "<AD Group For Password Reset>:CA;Reset Password;user"

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Self-Service Password Reset, Windows Azure Active Directory | Leave a Comment »

(2017-05-23) Bug In GPP Registry Wizard Prevents Registry Settings From Applying

Posted by Jorge on 2017-05-23


In the blog post (2017-03-01) Hardening – Disabling Weak Ciphers, Hashes And Protocols On ADFS, WAP, AAD Connect, Azure AD MFA Server And Azure AD Application Proxy I explain how to harden several hybrid identity related servers. I provide the individual settings and I also provide at the end of the blog post how you can use a GPO to configure all the settings from AD. For the registry settings I configured one server using the REG ADD commands and then I used the Registry Wizard in the GPP to consume all the settings I configured. The GPO I used also contained other regular policy settings.

After having all the settings in the GPO as described above, I found out the registry settings specifically never were applied to the servers, although the GPO was being processed. I confirmed processing of the GPO by using GPRESULT remotely and locally. I also looked at the registry settings multiple times to see if I could find any anomalies, but unfortunately I did not see anything strange. Well it took me some time, but if you look very carefully there is something strange to it

image

Figure 1: Setting Registry Values Through A GPO

I’m going to spare you the time that it took me to find what was wrong and guide you through the steps so that you understand where it goes wrong and how you can fix it.

If you look at figure 2 below what are you noticing? Hint: Look at the values in every column!

Correct! The “Hive” column does not have any value specified. THAT is the reason the registry setting is not applied at all to targeted servers

image

Figure 2: A Sample Registry Setting That Was Read Through The Registry Wizard – Empty Hive Value

However, if you open a registry setting for which the “Hive” value is not listed as shown in figure 2, you can see in figure 3, the “Hive” value IS listed. Confusing right?!

image

Figure 3: A Sample Registry Setting That Was Read Through The Registry Wizard – Populated Hive Value

The solution here is to reconfigure the “Hive value and committing the change into the GPO. Bu if you look at the [Apply] button figure 3 you see it is grayed out.

As shown in figure 4 just reselect the already listed “Hive” value.

image

Figure 4: A Sample Registry Setting That Was Read Through The Registry Wizard – Reselecting The Hive Value

After doing that the [Apply] button becomes available to be clicked/pressed.

image

Figure 5: A Sample Registry Setting That Was Read Through The Registry Wizard – Recommitting The Hive Value

After you have clicked/pressed the [Apply] button, you can see the “Hive” value is indeed populated as shown in the figure 6.

image

Figure 6: Sample Registry Setting That Was Read Through The Registry Wizard – Populated Hive Value For One Setting

Now do this for every registry setting read by the wizard

image

Figure 7: Sample Registry Setting That Was Read Through The Registry Wizard – Populated Hive Value For Another Setting

Because the “Hive” value was not specified for the registry settings in the GPO, those same registry settings were not applied, although the GPO that contained them was processed! Respecifying the “Hive” value solved the problem. And yes you will have to do this for every registry setting.

This issue only occurs when you use the Registry Wizard within the GPP and specify a remote server as the target server. If you specify the local server as the target then “Hive” value is populated correctly.

This occurred on both W2K12R2 and W2K16 servers

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Group Policy Objects, Group Policy Preferences | Leave a Comment »

(2017-05-17) Azure AD MFA Server v7.3.0.3 Has Been Released

Posted by Jorge on 2017-05-17


Microsoft has released a newer version of the Azure AD MFA server. If you start the MFA Server Console you should see a notification about a newer version being available.

Release notes: https://pfweb.phonefactor.net/install/7.3.0.3/release_notes.txt

Version 7.3.0.3 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

  • AD FS adapter performance improvements
  • Tags performance improvements
  • Log request IDs to allow correlation with backend logs
  • Modified AD sync service to clear phone numbers that are cleared in the directory
  • Fix for RADIUS one-way text message fallback to OATH token
  • Fix for passwords that contain leading or trailing spaces
  • Fix AD FS adapter to handle cultures that aren’t associated with a locale ID
  • Change mobile app references from Azure Authenticator to Microsoft Authenticator

Known Issues:

  • Windows Authentication for Terminal Services is not supported for Windows Server 2012 R2

Upgrade Considerations:

  • Must upgrade MFA Server and Web Service SDK before upgrading AD FS adapter
  • All other features and components are backwards-compatible with all previous versions

More information about Azure AD MFA Server can be found here.

Upgrade steps can be found here, but also take the following info into account

For this version of the MFA server:

  • you need to have MS-KB2919355 installed on the MFA server before starting the installation (check with Get-HotFix KB2919355)
  • you need to have the following installed on any server with any MFA server component: The Visual C++ 2015 Update 3 Redistribution packages are also available (x86, x64),

Before upgrading/installing the new ADFS adapter, you need to unselect and unregister the previous ADFS adapter

  • Using WID?: Execute the commands below on primary ADFS server and wait at least 5 minutes to allow WID replication to take place and finish
  • Using SQL?: Execute the commands below on any ADFS server

# Unselecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders
$listOfNewMFAProviders.Remove("WindowsAzureMultiFactorAuthentication")  # Use THIS line if the old version is v6.3.0 or lower
$listOfNewMFAProviders.Remove("AzureMfaServerAuthentication")  # Use THIS line if the old version is v7.0.0.9 or higher
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Unregistering The Azure AD MFA Adapter Within ADFS
Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication  # Use THIS line if the old version is v6.3.0 or lower
Unregister-AdfsAuthenticationProvider -Name AzureMfaServerAuthentication  # Use THIS line if the old version is v7.0.0.9 or higher

After installing the new ADFS adapter, you need to configure it, register it and configure it within ADFS

  • Using WID?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on the primary ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards
  • Using SQL?: EDIT The file “MultiFactorAuthenticationAdfsAdapter.config” on any ADFS server as explained below (use your previous settings where applicable), and SAVE it afterwards

FILE: MultiFactorAuthenticationAdfsAdapter.config

<ConfigurationData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <UseWebServiceSdk><true OR false></UseWebServiceSdk>

    <WebServiceSdkUrl><URL to the MFA Web Service SDK></WebServiceSdkUrl>

    <WebServiceSdkUsername><the account (DOMAIN\SAMACCOUNTNAME) the user portal is also using in its web.config></WebServiceSdkUsername>

    <WebServiceSdkPassword><the password of the account above the user portal is also using in its web.config></WebServiceSdkPassword>

    <WebServiceSdkCertificateThumbprint><thumbprint of certificate of web service sdk></WebServiceSdkCertificateThumbprint>

    <AutomaticallyTriggerUserDefaultMethod><true OR false></AutomaticallyTriggerUserDefaultMethod>

    <TestMode><true OR false></TestMode>

</ConfigurationData>

Now we need to register and configure the new ADFS adapter within ADFS

# Registering The Azure AD MFA Adapter Within ADFS

$typeName = "pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=7.3.0.3, Culture=neutral, PublicKeyToken=f300afd708cefcd3"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name AzureMfaServerAuthentication –ConfigurationFilePath "<Provide Path To MultiFactorAuthenticationAdfsAdapter.config>"

# Selecting The Use Of Azure AD MFA Adapter To Be Listed
$listOfCurrentMFAProviders = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
$listOfNewMFAProviders = $listOfCurrentMFAProviders + "AzureMfaServerAuthentication"
Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $listOfNewMFAProviders

# Configuring Custom Display Name And Custom Description
Set-AdfsAuthenticationProviderWebContent -Name "AzureMfaServerAuthentication" -DisplayName "<Provide Custom DisplayName>" -Description "<Provide Custom Description>"

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

 
%d bloggers like this: