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!

(2018-10-20) Grant, Revoke Or Query For User Rights (Privileges) Using PowerShell

Posted by Jorge on 2018-10-20


Have you ever needed to script granting or revoking user rights, or maybe just querying for user rights? If the answer is “Yes”, most likely you have had to use NTRIGHTS from the good old Windows Server 2003 Resource Kit or do some funky magic around SECEDIT. It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around user rights locally and remotely on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage user rights can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can modify any user right; is not limited to "Logon as a Service"
  • Can add/remove rights from the current process token
  • Doesn’t write temporary files during operation
  • Fully pipeline-able
  • Pure PowerShell implementation
  • Supports changing user rights on remote machines
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 3.0
  • Administrative rights on target computer, or elevation on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016, Server Core 1709

Available Cmdlets:

  • Grant-UserRight
  • Revoke-UserRight
  • Get-UserRightsGrantedToAccount
  • Get-AccountsWithUserRight
  • Grant-TokenPrivilege
  • Revoke-TokenPrivilege

 

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/ ###################
————————————————————————————————————————————————————-

Advertisements

Posted in User Rights, User Rights, Windows Client, Windows Server | Leave a Comment »

(2018-10-11) Configuring A New Identity Store As A Local Claims Provider In ADFS

Posted by Jorge on 2018-10-11


In ADFS v1.0 and ADFS v1.1 it was possible to use both AD and ADLDS/ADAM as an identity store. One of the very common scenarios is to use the AD identity store for internal users and use the ADLDS/ADAM identity store for external users (e.g. partners, customers, vendors, etc.). After ADFS v1.x Microsoft released ADFS v2.0 (separate download for W2K8 and W2K8R2), ADFS v2.1 in W2K12 and ADFS v3.0 in W2K12R2. All the ADFS versions starting with ADFS v2.0 and higher only supported AD as the identity store and nothing else. That could be one of the reasons why some companies remained using ADFS v1.1 and did not move one.

If you would like to support a similar scenario, where you would like to have a separate identity store for externals, you would need to:

  1. Configure a separate AD with its own ADFS infrastructure and configure federation between (also see: (2013-09-24) AD User Accounts For Which The ADFS STS Can Generate Security Tokens)
    OR
  2. Use Azure AD to store those identities and configure federation

The biggest advantage of using [2] instead of [1] is that you do not need a complete new infrastructure just to support externals. The basic Azure AD features are free, but as soon as you need something special from the Azure AD Premium list, you need to pay licensing.

With the release of the Windows Server 2016, a third option has become available as already mentioned in the blog post (2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only. YES! YES! YES! Finally!

For the passive federation protocols (e.g. SAML, WS-Federation and Oauth) and the active federation protocols (e.g. WS-Trust), ADFS v4.0 (ADFS in Windows Server 2016) and higher will support the following identity stores:

  • Identity Stores As Claim Providers:◦Active Directory (Trusted AD forests)
  • Identity Stores As Local Claim Providers:◦Active Directory (NON-Trusted AD forests)
    • ADLDS/ADAM
    • Apache DS
    • IBM Tivoli DS
    • Novell DS
    • Open LDAP
    • Open DJ
    • Open DS
    • Radiant Logic Virtual DS
    • Sun ONE v6, v7, v11

The local claims providers can only be configured through PowerShell and authentication through ADFS against those local claims providers can only be done by using forms-based authentication. One last thing to note is that you can only configure local claims providers when the Farm Behavior/Level is higher than Win2012R2. Also see: (2014-10-12) Migrating Or Upgrading To A New ADFS Version.

For more information also see:

I have the following Identity (ID) Store:

  • Type: ADLDS (LDAP)
  • Node Server (1): R1FSRWDC1.IAMTEC.NET
    • LDAP Port: 5389
    • LDAPS Port: 5636
  • Node Server (2): R1FSRWDC2.IAMTEC.NET
    • LDAP Port: 5389
    • LDAPS Port: 5636
  • Account UserName For ADFS To Access data In The IDStore: SVC_R1_LDAPQuery@CORP

# Define The Credentials For ADFS To Use When Connecting To The ID Store

$idStoreAccountUserName = ‘SVC_R1_LDAPQuery@CORP’

$idStoreAccountPassword = ‘pwd’ | ConvertTo-SecureString -asPlainText -Force

$idStoreAccountCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $idStoreAccountUserName,$idStoreAccountPassword

# Define All The Server Instances Hosting The Identity Store

$idStoreInstance1 = New-AdfsLdapServerConnection -HostName R1FSRWDC1.IAMTEC.NET -Port 5389 -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

$idStoreInstance2 = New-AdfsLdapServerConnection -HostName R1FSRWDC2.IAMTEC.NET -Port 5389 -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

PS: If you have a load balanced ADLDS farm than you would only need to define one connection instance as the load balancer would figure out which node to use. For more information about load balancing ADLDS please see: https://www.itprotoday.com/management-mobility/load-balance-ad-lds-microsoft-nlb-6-steps. If you do not have a load balanced ADLDS farm you need to define all connection instances so that ADFS can figure out which one to use. In the connection above I’m using the custom LDAP port (5389) configured by me. I did this as I was too lazy for this post to get an SSL certificate for LDAPS. For production systems I do suggest you use LDAPS!. For more information please see: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725767(v=ws.10)

# Define All The Attribute-To-ClaimType Mappings For Which You Want ADFS To Automatically Retrieve From The ID Store

# (These are the attributes and their values, if any, automatically retrieved from the ID store and stored in claims, whether or not these are issued later on in a security token)

$mappingGivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"

$mappingSurname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"

$mappingDisplayName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute displayName -ClaimType "http://temp.org/identity/claims/displayName"

$mappingEmployeeID = New-AdfsLdapAttributeToClaimMapping -LdapAttribute employeeID -ClaimType "http://temp.org/identity/claims/employeeID"

$mappingDescription = New-AdfsLdapAttributeToClaimMapping -LdapAttribute description -ClaimType "http://temp.org/identity/claims/description"

# Create The Local Claims Provider Trust To Appear In The HRD Screen Through A List Of Claims Providers

Add-AdfsLocalClaimsProviderTrust -Name "External ID Store" -Identifier "urn:adlds:external:idstore" -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer "OU=People,O=CORP" -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription) -Enabled $true -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => issue(claim = c);"

OR

# Create The Local Claims Provider Trust To Appear In The HRD Screen Through UPN Suffix

Add-AdfsLocalClaimsProviderTrust -Name "External ID Store" -Identifier "urn:adlds:external:idstore" -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer "OU=People,O=CORP" -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription) -Enabled $true -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => issue(claim = c);"

Now when running either of the “Add-AdfsLocalClaimsProviderTrust” CMDlets you may see the following error at the end. It is really vague and does not tell you anything about what is really wrong. At first I thought something was wrong with the database.

image

Figure 1: Creating The Local Claims Provider Trust Fails With An Error

When things go wrong, the first thing I look at is the event log of the specific application/system. In this case it was the ADFS Admin Event Log. It did not say anything about this error. Knowing that I thought it would took me hours to figure this out. Au contraire!. Looking at the ADFS Debug Event Log, I saw the following message. It was referencing the Certificate Sharing Container.

image

Figure 2: Error Message In The ADFS Debug Event Log

An error occurred while trying to add an object:
Message: MSIS0013: Encrypted property ‘AccountStoreData’ cannot be set when a certificate sharing container is not configured in AD FS properties.

It was a weird error, because my ADFS farm is NOT using automatic certificate rollover and therefore it does not need the Certificate Sharing Container. You can see in the figure below that is the case. My farm is using CA issued certificates for the Token Signing Certificate and the Token Encryption Certificate.

image

Figure 3: Certificate Rollover NOT Being Enabled And The Certificate Sharing Container Not Being Configured

The Certificate Sharing Container is related to ADFS using ADFS Managed Self-Signed Certificates for the Token Signing Certificate and the Token Encryption Certificate. When the “AutoCertificateRollover” is set to TRUE, the “CertificateSharingContainer” property MUST specify the DN of the Certificate Sharing Container in AD. The ADFS servers and the Certificate Sharing Container must be in the same AD domain. When the “AutoCertificateRollover” is set to FALSE, the “CertificateSharingContainer” property CAN have a DN specified but in that case it is not being and can be removed if needed (but only when you are not going to use it in the future!).

Well, because the error was mentioning the Certificate Sharing Container and I did not have a Certificate Sharing Container, I decided to create one. When doing so you need to specify the service account in use by ADFS. I did that by reading the account from the ADFS service. Please be aware that by configuring the Certificate Sharing Container in ADFS, it will also be created in AD. Because of that you need to have Domain Admin equivalent permissions to be able to successfully do this!

$adfsService = Get-WmiObject win32_service -filter "name=’ADFSSRV’"
$adfsServiceAccount = $adfsService.StartName
Set-AdfsCertSharingContainer -ServiceAccount $adfsServiceAccount

image

Figure 4: Configuring The Certificate Sharing Container For ADFS

Now looking at the ADFS properties you can see the Certificate Sharing Container is configured in ADFS.

image

Figure 5: The Certificate Sharing Container Being Configured For ADFS

Before the configuration in ADFS you can see AD did not have a Certificate Sharing Container.

image

Figure 6: The AD Domain The ADFS Servers Are In With NO Certificate Sharing Container

After the configuration in ADFS you can see AD now does have a Certificate Sharing Container.

image

Figure 7: The AD Domain The ADFS Servers Are In With Certificate Sharing Container

Now when running either of the “Add-AdfsLocalClaimsProviderTrust” CMDlets above succeeds!

image

Figure 8: Creating The Local Claims Provider Trust Now Succeeds

Below you can see the properties of the Local Claims Provider trust that was created.

image

Figure 9: The Configuration Of The Local Claims Provider Trust That Was Just Created

And now you also see the local Claims Provider Trust is displayed and therefore available in the HRD page in ADFS.

image

Figure 10: The HRD Page In ADFS Showing The Newly Created Local Claims Provider Trust

Choosing the IdP “External ID Store” and logging on with an account from the ADLDS based ID Store through Forms Based Authentication, show amongst others the claims as displayed in the figure below.

image

Figure 11: My Show My Claims Application Displaying The Claims That Were Retrieved From The ID Store Based Upon ADLDS

You can see the values for the following claims that were configured above:

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), Active Directory Lightweight Directory Services (ADLDS), Identity Stores | 2 Comments »

(2018-10-09) Changing AD CP Trust Display Name And Order In ADFS 2016 Farm Level And Higher

Posted by Jorge on 2018-10-09


You are currently running ADFS 2012 R2 and you are planning on upgrading (yes, you can upgrade!) to ADFS 2016. Your Home Realm Discovery (HRD) page is looking similar to the one in figure 1, meaning that the AD CP trust is listed at the top and that it inherits the Display Name of the federation service. So far so good , right?

image

Figure 1: A Home Realm Discovery Web Page In ADFS 2012 R2 Or ADFS 2016 When At ADFS 2012 R2 Farm Level

After adding ADFS 2016 servers and removing the ADFS 2012 R2 servers, it is time to increase the farm level to the highest farm level possible.

You “throw the switch” and suddenly your HRD page looks similar to the one as displayed in figure 2. Damn!

image

Figure 2: A Home Realm Discovery Web Page In ADFS 2016 When At, At Least ADFS 2016 Farm Level

From a user perspective, that can be quite some impact as user to not expect “their default selection” to have moved to the bottom. Worse yet, the users might not even recognize it because the trust display name does not inherit the display name of the federation service anymore. It just shows as “Active Directory”, which is a technical name. You might think in changing the display name of the “Active Directory” CP trust to match whatever you need. Let me save you the trouble of trying that, because, it is not allowed to change much including the display name.

So, one simple change (farm level increase) results in an unfortunate functional impact for users.

What can you do about this? The solution to this problem is to implement some extra javascript code in the ONLOAD.JS.

To make sure your current web theme is not broken while making this change, make sure to first create a new web theme and implement the changes in that new web theme. So let’s get started!

Retrieve the name of your CURRENT web theme

Get-AdfsWebConfig

In the property called “ActiveThemeName” you will find the name of the current theme that is active and in use by everyone.

Make a copy of that theme and give the copy a new name:

New-AdfsWebTheme -Name <New WebTheme Name> -SourceName <Current Active WebTheme Name>

Export the new web theme to be able to edit it:

MD <Path To Export The Theme To>

Export-AdfsWebTheme -Name <New WebTheme Name> -DirectoryPath <Path To Export The Theme To>

Open the ONLOAD.JS file

NOTEPAD "<Path To Export The Theme To>\script\onload.js"

Edit the ONLOAD.JS file by adding a piece of javascript code at the end of it. It will put the AD CP trust at the top again and it will rename it to the display name of your choosing. It has been tested with the following browsers: IE, Edge, Chrome, Firefox, Safari.
REMARK: Make sure to follow guidelines as available in
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/advanced-customization-of-ad-fs-sign-in-pages

The javascript code is available at: https://github.com/microsoft/adfsWebCustomization/tree/master/communityCustomizations/RenameAndReorderADCPTrust

Save the ONLOAD.JS file

Import the new ONLOAD.JS into the new web theme

Set-AdfsWebTheme -TargetName <New WebTheme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Path To Export The Theme To>\script\onload.js"}

Now it is time to activate the new web theme and check it has been activated

Set-AdfsWebConfig -ActiveThemeName <New WebTheme Name>

Get-AdfsWebConfig

Now make sure to clear your cookies, and navigate to an application connected to ADFS for which more than one CP trust is allowed to use. In that case, assuming you have cleared your cookies, the HRD page should appear and it should again be similar to what you see in figure 1.

If you need to revert back to your previous current web theme, you new to activate it as such and check it has been activated

Set-AdfsWebConfig -ActiveThemeName <Current Active WebTheme Name>

Get-AdfsWebConfig

PS: make sure to test this first in a test environment!

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), Configuration, Federation Trusts, Home Realm Discovery (HRD), Migration, onload.js | Leave a Comment »

(2018-10-07) Presenting At Hybrid Identity Protection (HIP) Conference In New York

Posted by Jorge on 2018-10-07


As we speak, I’m preparing my presentation and demo’s for my presentation at the Hybrid Identity Protection (HIP) conference in New York. You can get more information, and of course register (did you already register?) through the following link https://www.hipconf.com/. The conference dates are Monday November 5th and Tuesday November 6th.

The Speaker List: https://www.hipconf.com/speakers/

The Agenda: https://www.hipconf.com/agenda/

My session is scheduled for Monday November 5th at 5 PM (17:00) and is called “How To Secure Shared Social Media Accounts And Achieve SSO Through Azure AD”

Abstract:

Nowadays many companies have an online presence in most likely more than one social media to at least service and/or communicate with customers regarding all kinds of matters. Some well-known examples are Twitter, Facebook, Instagram and YouTube. Of course, other social media may exist specific to the business or country.

The main question is: how can you make sure those (shared) social media accounts are used in a secure manner by a group of people and still keep the bad guys out?

The answer is: That’s where Azure AD comes into the playing field!

Come to this session to learn and see about experiences using the Azure AD solution. Yes, demos are included!

See you there!

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 Conferences, Windows Azure Active Directory | Leave a Comment »

(2018-10-07) Azure AD MFA Server v8.0.1.1 Has Been Released

Posted by Jorge on 2018-10-07


Azure Multi-Factor Authentication Server provides a way to secure resources with MFA capabilities

Download "Azure Multi-Factor Authentication Server"

Azure Multi-Factor Authentication Server

8.0.1.1

Released: 7/26/2018

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.

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

  • Fixed issue with launching MFA Server UX on Japanese version of Windows
  • Fixed issue with retaining selected language in user portal
  • Other minor bug fixes

Upgrade Considerations:

  • Must upgrade MFA Server and Web Service SDK before upgrading User Portal And AD FS adapter
  • All other features and components are backwards-compatible with all previous versions
  • Installation of the mobile app web service is not necessary for v8.0 or higher. Complete only the steps under Configure the mobile app. After the upgrade you may want to uninstall the previous mobile app web service, remove the virtual directory and application pool from IIS. If you have published the mobile app web service, then that is not required anymore

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++ 2017 Redistribution packages (a.k.a. Visual C++ "14" Runtime Libraries) are also available from here
  • you need to have the at least following version installed on any server with any MFA server component: .NET Framework 4.6.2 is available from here.

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=8.0.1.1, 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>"

I upgraded from the previous version without any issues!

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 Uncategorized | Leave a Comment »

(2018-10-07) Azure AD Connect v1.1.882.0 Has Been Released

Posted by Jorge on 2018-10-07


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.1.882.0

Released: 9/7/2018

Released for download, will not be released for auto upgrade

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Fixed Issues:

  • Azure AD Connect Upgrade fails if SQL Always On Availability is configured for the ADSync DB. This hotfix addresses this issue and allows Upgrade to succeed

I (finally) ran the MSI and upgraded from the previous version without any issues!

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 | Leave a Comment »

(2018-10-07) Azure AD Connect v1.1.880.0 Has Been Released

Posted by Jorge on 2018-10-07


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.1.880.0

Released: 8/21/2018

Released for auto upgrade and download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements:

  • The Ping Federate integration in Azure AD Connect is now available for General Availability. Learn more about how to federated Azure AD with Ping Federate
  • Azure AD Connect now creates the backup of Azure AD trust in AD FS every time an update is made and stores it in a separate file for easy restore if required. Learn more about the new functionality and Azure AD trust management in Azure AD Connect.
  • New troubleshooting tooling helps troubleshoot changing primary email address and hiding account from global address list
  • Azure AD Connect was updated to include the latest SQL Server 2012 Native Client
  • When you switch user sign-in to Password Hash Synchronization or Pass-through Authentication in the "Change user sign-in" task, the Seamless Single Sign-On checkbox is enabled by default.
  • Added support for Windows Server Essentials 2019
  • The Azure AD Connect Health agent was updated to the latest version 3.1.7.0
  • During an upgrade, if the installer detects changes to the default sync rules, the admin is prompted with a warning before overwriting the modified rules. This will allow the user to take corrective actions and resume later. Old Behavior: If there was any modified out-of-box rule then manual upgrade was overwriting those rules without giving any warning to the user and sync scheduler was disabled without informing user. New Behavior: User will be prompted with warning before overwriting the modified out-of-box sync rules. User will have choice to stop the upgrade process and resume later after taking corrective action.
  • Provide a better handling of a FIPS compliance issue, providing an error message for MD5 hash generation in a FIPS compliant environment and a link to documentation that provides a work around for this issue.
  • UI update to improve federation tasks in the wizard, which are now under a separate sub group for federation.
  • All federation additional tasks are now grouped under a single sub-menu for ease of use.
  • A new revamped ADSyncConfig Posh Module (AdSyncConfig.psm1) with new AD Permissions functions moved from the old ADSyncPrep.psm1 (which may be deprecated shortly)

Fixed Issues:

  • Fixed a bug where the AAD Connect server would show high CPU usage after upgrading to .Net 4.7.2
  • Fixed a bug that would intermittently produce an error message for an auto-resolved SQL deadlock issue
  • Fixed several accessibility issues for the Sync Rules Editor and the Sync Service Manager
  • Fixed a bug where Azure AD Connect can not get registry setting information
  • Fixed a bug that created issues when the user goes forward/back in the wizard
  • Fixed a bug to prevent an error happening due to incorrect multi thread handing in the wizard
  • When Group Sync Filtering page encounters an LDAP error when resolving security groups, Azure AD Connect now returns the exception with full fidelity. The root cause for the referral exception is still unknown and will be addressed by a different bug.
  • Fixed a bug where permissions for STK and NGC keys (ms-DS-KeyCredentialLink attribute on User/Device objects for WHfB) were not correctly set.
  • Fixed a bug where ‘Set-ADSyncRestrictedPermissions’ was not called correctly
  • Adding support for permission granting on Group Writeback in AADConnect’s installation wizard
  • When changing sign in method from Password Hash Sync to AD FS, Password Hash Sync was not disabled.
  • Added verification for IPv6 addresses in AD FS configuration
  • Updated the notification message to inform that an existing configuration exists.
  • Device writeback fails to detect container in untrusted forest. This has been updated to provide a better error message and a link to the appropriate documentation
  • Deselecting an OU and then synchronization/writeback corresponding to that OU gives a generic sync error. This has been changed to create a more understandable error message

I (finally) ran the MSI and upgraded from the previous version without any issues!

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 | Leave a Comment »

(2018-10-07) Oh My Dear Blog – How Much I Have Neglected You!

Posted by Jorge on 2018-10-07


It has been quite some time since I blogged quite frequently. Due to family reasons (my mom passed away after being ill for quite a long time) I was not able to post all kinds of stuff on my blog. There was just too much emotion and I ended up with a huge amount of work that had the highest priority and that I wanted to finish before doing anything else.

Now, while getting back on track again, I hope to pick up where I "left" and start blogging again any time soon about all kinds of stuff I have in mind.

Thanks.

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 Day-To-Day Stuff | Leave a Comment »

(2018-07-22) Azure AD Connect v1.1.819.0 Has Been Released

Posted by Jorge on 2018-07-22


Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.1.819.0

Released: 5/14/2018

Released for auto upgrade and download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements:

  • This release includes the public preview of the integration of PingFederate in Azure AD Connect. With this release, customers can easily, and reliably configure their Azure Active Directory environment to leverage PingFederate as their federation provider. To learn more about how to use this new feature, please visit our online documentation.
  • Updated the Azure AD Connect Wizard Troubleshooting Utility, where it now analyzes more error scenario’s, such as Linked Mailboxes and AD Dynamic Groups. Read more about the troubleshooting utility here.
  • Device Writeback configuration is now managed solely within the Azure AD Connect Wizard.
  • A new PowerShell Module called ADSyncTools.psm1 is added that can be used to troubleshoot SQL Connectivity issues and various other troubleshooting utilities. Read more about the ADSyncTools module here.
  • A new additional task “Configure device options” has been added. You can use the task to configure the following two operations:
    • Hybrid Azure AD join: If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD joined devices. These are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory.
    • Device writeback: Device writeback is used to enable conditional access based on devices to AD FS (2012 R2 or higher) protected devices

Note:

  • The option to enable device writeback from Customize synchronization options will be greyed out.
  • The PowerShell module for ADPrep is deprecated with this release.

Fixed Issues:

  • This release updates the SQL Server Express installation to SQL Server 2012 SP4, which, among others, provides fixes for several security vulnerabilities. Please see here for more information about SQL Server 2012 SP4.
  • Sync Rule Processing: outbound Join sync rules with no Join Condition should be de-applied if the parent sync rule is no longer applicable
  • Several accessibility fixes have been applied to the Synchronization Service Manager UI and the Sync Rules Editor
  • Azure AD Connect Wizard: Error creating AD Connector account when Azure AD Connect is in a workgroup
  • Azure AD Connect Wizard: On the Azure AD Sign-in page display the verification checkbox whenever there is any mismatch in AD domains and Azure AD Verified domains
  • Auto-upgrade PowerShell fix to set auto upgrade state correctly in certain cases after auto upgrade attempted.
  • Azure AD Connect Wizard: Updated telemetry to capture previously missing information
  • Azure AD Connect Wizard: The following changes have been made when you use the Change user sign-in task to switch from AD FS to Pass-through Authentication:
    • The Pass-through Authentication Agent is installed on the Azure AD Connect server and the Pass-through Authentication feature is enabled, before we convert domain(s) from federated to managed.
    • Users are no longer converted from federated to managed. Only domain(s) are converted.
  • Azure AD Connect Wizard: AD FS Multi Domain Regex is not correct when user UPN has ‘ special character Regex update to support special characters
  • Azure AD Connect Wizard: Remove spurious "Configure source anchor attribute" message when no change
  • Azure AD Connect Wizard: AD FS support for the dual federation scenario
  • Azure AD Connect Wizard: AD FS Claims are not updated for added domain when converting a managed domain to federated
  • Azure AD Connect Wizard: During detection of installed packages, we find stale Dirsync/Azure AD Sync/Azure AD Connect related products. We will now attempt to uninstall the stale products.
  • Azure AD Connect Wizard: Correct Error Message Mapping when installation of passthrough authentication agent fails
  • Azure AD Connect Wizard: Removed "Configuration" container from Domain OU Filtering page
  • Sync Engine install: remove unnecessary legacy logic that occasionally failed from Sync Engine install msi
  • Azure AD Connect Wizard: Fix popup help text on Optional Features page for Password Hash Sync
  • Sync Engine runtime: Fix the scenario where a CS object has an imported delete and Sync Rules attempt to re-provision the object.
  • Sync Engine runtime: Add help link for Online connectivity troubleshooting guide to the event log for an Import Error
  • Sync Engine runtime: Reduced memory usage of Sync Scheduler when enumerating Connectors
  • Azure AD Connect Wizard: Fix an issue resolving a custom Sync Service Account which has no AD Read privileges
  • Azure AD Connect Wizard: Improve logging of Domain and OU filtering selections
  • Azure AD Connect Wizard: AD FS Add default claims to federation trust created for MFA scenario
  • Azure AD Connect Wizard: AD FS Deploy WAP: Adding server fails to use new certificate
  • Azure AD Connect Wizard: DSSO exception when onPremCredentials aren’t initialized for a domain
  • Preferentially flow the AD distinguishedName attribute from the Active User object.
  • Fixed a cosmetic bug were the Precedence of the first OOB Sync Rule was set to 99 instead of 100

I (finally) ran the MSI and upgraded from the previous version without any issues!

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 | Leave a Comment »

(2018-07-02) Re-Awarded For The 13th Time–MVP Enterprise Mobility (Identity And Access)

Posted by Jorge on 2018-07-02


Oops, I did it again! Smile

On July 1st I received an e-mail from Microsoft I was re-awarded again with the MVP Award for Enterprise Mobility in the Identity And Access Area. This year is the thirteenth time I have received this award! Smile

PS: I was awarded the first time on January 1st 2006, and since back then I have been re-awarded every January of each year. Since this year Microsoft changed the award cycle so that everyone, if awarded, is awarded on July 1st. So as of July 1st I have been an MVP for 13,5 years and this time is the 13th time.

Let’s go for yet another year! Whooohooo! Smile

image

13x  image_thumb2_thumb_thumb_thumb_thumb

(13,5 years of Community Service)

!!! THANKS MICROSOFT !!!

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 MVP | Leave a Comment »

 
%d bloggers like this: