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!

(2019-08-04) Required Permissions For Azure AD Connect

Posted by Jorge on 2019-08-04


The document Azure AD Connect: Accounts and permissions provides information on which accounts require which permissions. One thing that is certain is that I would NEVER install Azure AD Connect using the Express Installation option. Why? The AD Connector account ends up with domain/enterprise admin permissions, which is TOO MUCH to give away.

In addition, my recommendations are:

  • Do not use Express Install
  • Use a gMSA where possible for the Azure AD Connect Sync Service
  • Assign a custom made user account for the AD Connector Account (a.k.a. AD MA account) with a very long (strong) password and make you audit/monitoring changes in this account as it may be very powerful when configured to support PHS and/or configured on the adminSDholder object
  • Delegate permissions to the AD Connector Account instead of “give it all”. See below for a non-exhaustive list of delegations

Active Directory – Permissions:

Permissioned Object

Assigned/Required Permission

Security Principal Using Permission

Permission Assigned Through (Just A Suggestion!)

DC=<DOMAIN>,DC=<TLD>

* “Allow:Replicating Directory Changes” for “This Object Only”

* “Allow:Replicating Directory Changes ALL” for “This Object Only” (only needed for PHS!)

<DOMAIN>\<AD Connector Account>

<DOMAIN>\<AD Group For DS Repl Changes> (security group)

<DOMAIN>\<AD Group For DS Repl Changes All> (security group)

CN=RegisteredDevices,DC=<DOMAIN>,DC=<TLD>

* “Allow:Full Control” for “Descendant msDS-Device Objects” (only needed for device writeback!)

* “Allow:Create msDS-Device Objects” for “This Object Only” (only needed for device writeback!)

* “Allow:Delete msDS-Device Objects” for “This Object Only” (only needed for device writeback!)

<DOMAIN>\<AD Connector Account> Directly

<On The AdminSDHolder Object Of Any Domain>

CN=AdminSDHolder,CN=System,DC=<DOMAIN>,DC=<TLD>

* “Allow:Read/Write On <Immutable ID Attribute>” (only needed to manage “admin” objects)

* “Allow:Read/Write On msDS-ExternalDirectoryObjectId” (only needed to manage “admin” objects)

* “Allow:Read/Write On pwdLastSet” (only needed for Password Writeback/SSPR for “admin” accounts!)

* “Allow:Password Reset” (only needed for Password Writeback/SSPR for “admin” accounts!)

* “Allow:Read/Write On lockoutTime” (only needed for Password Writeback/SSPR for “admin” accounts!)

<DOMAIN>\<AD Connector Account> Directly
<On Any Domain At Domain Level>

* “Allow:Read/Write On <Immutable ID Attribute>” for “Descendant user Objects”

* “Allow:Read/Write On msDS-ExternalDirectoryObjectId” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msExchArchiveStatus” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msExchBlockedSendersHash” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msExchSafeRecipientsHash” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msExchSafeSendersHash” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msExchUCVoiceMailSettings” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msExchUserHoldPolicies” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On proxyAddresses” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On publicDelegates” for “Descendant user Objects” (only needed for Hybrid Exchange!)

* “Allow:Read/Write On msDS-KeyCredentialLink” for “Descendant user Objects” (only needed for for WH4B)

<DOMAIN>\<AD Connector Account> <DOMAIN>\<AD Group For Writeback Attributes> (security group)
<On Any Domain At Domain Level>

*Allow:Read/Write On <Immutable ID Attribute>” for “Descendant group Objects”

* “Allow:Read/Write On proxyAddresses” for “Descendant group Objects” (only needed for Hybrid Exchange!)

<DOMAIN>\<AD Connector Account> <DOMAIN>\<AD Group For Writeback Attributes> (security group)
<On Any Domain At Domain Level> * “Allow:Read/Write On lockoutTime” for “Descendant user Objects” (only needed for Password Writeback/SSPR!) <DOMAIN>\<AD Connector Account> <DOMAIN>\<AD Group For Writeback Password Or Just Account Unlock> (security group)
<On Any Domain At Domain Level>

* “Allow:Read/Write On pwdLastSet” for “Descendant user Objects” (only needed for Password Writeback/SSPR!)

* “Allow:Password Reset” for “Descendant user Objects” (only needed for Password Writeback/SSPR!)

<DOMAIN>\<AD Connector Account> <DOMAIN>\<AD Group For Writeback Password Or Just Password Reset> (security group)
<On Any Domain At Domain Level> * “Allow:Read/Write On proxyAddresses” for “Descendant contact Objects” (only needed for Hybrid Exchange!) <DOMAIN>\<AD Connector Account> <DOMAIN>\<AD Group For Writeback Attributes> (security group)

REMARK: to configure the required permissions at domain level for any domain so that the AD MA/Connector can sync (write) into AD for user accounts or group objects, the following commands can be used (make sure to customize as needed for your environment!!!):

# CONSTANTS

$dcFQDN = "<FQDN Of The Nearest RWDC Of Domain>"

$domainDN = "<Domain Distinguished Name>"

$domainNBT = "<Domain NetBIOS Name>"

$aadConnectADConnectorAccount = "$domainNBT\<AD Connector Account>"

$dsReplChangesSecPrinc = "$domainNBT\<AD Group For DS Repl Changes>"

$dsReplChangesAllSecPrinc = "$domainNBT\<AD Group For DS Repl Changes All>"

$dnContainerUserObjects = "<DN of Container/OU With User Objects>"

$aadConnectWritebackAttributesUsersSecPrinc = "$domainNBT\<AD Group For Writeback Attributes Users>"

$aadConnectWritebackPasswordUsersSecPrinc = "$domainNBT\<AD Group For Writeback Password Users>"

$dnContainerGroupObjects = "<DN of Container/OU With Group Objects>"

$aadConnectWritebackAttributesGroupsSecPrinc = "$domainNBT\<AD Group For Writeback Attributes Groups>"

$dnContainerContactObjects = "<DN of Container/OU With Contact Objects>"

$aadConnectWritebackAttributesContactSecPrinc = "$domainNBT\<AD Group For Writeback Attributes Contacts>"

# GENERIC

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$domainDN’ /G ‘$dsReplChangesSecPrinc:CA;Replicating Directory Changes’"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$domainDN’ /G ‘$dsReplChangesAllSecPrinc:CA;Replicating Directory Changes’"

Invoke-Expression $dsaclsCMD | Out-Null

# DEVICE WRITEBACK

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\CN=RegisteredDevices,$domainDN’ /G ‘$aadConnectADConnectorAccount:GA;;msDS-Device Objects’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\CN=RegisteredDevices,$domainDN’ /G ‘$aadConnectADConnectorAccount:CCDC;msDS-Device Objects’ /I:T"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR ADMINSDHOLDER PROTECTED OBJECTS

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\CN=AdminSDHolder,CN=System,$domainDN’ /G ‘$aadConnectADConnectorAccount:RPWP;<Attribute To Write To>‘"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$domainDN’ /G ‘$aadConnectADConnectorAccount:CA;<CAR>‘"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR USER ACCOUNTS GENERIC

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;<Immutable ID Attribute>;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msDS-ExternalDirectoryObjectId;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR USER ACCOUNTS HYBRID EXCHANGE

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msExchArchiveStatus;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msExchBlockedSendersHash;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msExchSafeRecipientsHash;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msExchSafeSendersHash;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msExchUCVoiceMailSettings;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msExchUserHoldPolicies;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;proxyAddresses;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;publicDelegates;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR USER ACCOUNTS WINDOWS HELLO FOR BUSINESS

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackAttributesUsersSecPrinc:RPWP;msDS-KeyCredentialLink;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR USER ACCOUNTS PASSWORD WRITEBACK/SSPR

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackPasswordUsersSecPrinc:RPWP;lockoutTime;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackPasswordUsersSecPrinc:RPWP;pwdLastSet;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerUserObjects’ /G ‘$aadConnectWritebackPasswordUsersSecPrinc:CA;Reset Password;user’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR GROUP OBJECTS GENERIC

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerGroupObjects’ /G ‘$aadConnectWritebackAttributesGroupsSecPrinc:RPWP;<Immutable ID Attribute>;group’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

# FOR GROUP OBJECTS HYBRID EXCHANGE

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerGroupObjects’ /G ‘$aadConnectWritebackAttributesGroupsSecPrinc:RPWP;proxyAddresses;group’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null


# FOR CONTACT OBJECTS HYBRID EXCHANGE

$dsaclsCMD = "DSACLS ‘\\$dcFQDN\$dnContainerContactObjects’ /G ‘$aadConnectWritebackAttributesContactsSecPrinc:RPWP;proxyAddresses;contact’ /I:S"

Invoke-Expression $dsaclsCMD | Out-Null

Azure Active Directory Permissions:

An Azure AD Account with the “Global Administrator” role to be able to configure the AAD Sync Server during installation and any other subsequent configuration moment. This account may be enabled for MFA, but in that case cookies and javascript must be allowed on the server

Hope this helps you!

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 Azure AD Connect, Windows Azure Active Directory | 3 Comments »

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

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 Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | Leave a Comment »

(2019-07-30) ADFS Security: Disable WS-Trust Windows Transport Endpoints On PROXYs/WAPs (Extranet)

Posted by Jorge on 2019-07-30


Due to a known security vulnerability it is highly recommended that the WS-Trust Windows Transport Endpoints are disabled on the ADFS Proxies/WAPs (from the extranet). Be careful though that these endpoints are needed by Windows 10 and Windows Server 2016 and higher on the INTRANET side of ADFS to leverage Azure AD Domain Join, a.k.a. Hybrid Azure AD Domain Join (HAADJ). For more detail please see the section “ADFS Endpoints” in the blog post (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

When enabled on the EXTRANET side, it will allow NTLM logins to be processed from the extranet. As a result, it will bypass AD FS lockout protections and allow brute force password attacks or account lockouts on the user account, which of course is something you do not want! Also check out: Best practices for securing Active Directory Federation Services – ADFS Endpoints

What do you need to do?

Check the status of the WS-Trust ‘2005’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed. You can do that through the following PowerShell commands. When using SQL you can run the commands on any ADSF server. When using WID you need to run the commands on the primary ADFS server.

Clear-Host
$adfsWSTrust2005EndpointPath = "/adfs/services/trust/2005/windowstransport"
$adfsWSTrust2005 = Get-AdfsEndpoint -AddressPath $adfsWSTrust2005EndpointPath
If ($adfsWSTrust2005.Enabled -eq $true) {
    Write-Host ""
    Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The INTRANET Is ENABLED…" -ForegroundColor Green
    If ($adfsWSTrust2005.Proxy -eq $true) {
        Write-Host ""
        Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is ENABLED…" -ForegroundColor Red
        Write-Host "Due To A Security Vulnerability It Is Highly Recommended To Disable This Endpoint On The Extranet Side Of ADFS!…" -ForegroundColor Red
        Write-Host ""
        $confirmationAdfsWSTrust2005 = Read-Host "Do You Want To Disable This Endpoint On The Extranet Side? [Yes|No]"
        If ($confirmationAdfsWSTrust2005.ToUpper() -eq "YES" -Or $confirmationAdfsWSTrust2005.ToUpper() -eq "Y") {
            Set-AdfsEndpoint -TargetAddressPath $adfsWSTrust2005EndpointPath -Proxy $false           
            Write-Host ""
            Write-Host "Action Confirmed…" -ForegroundColor Green
            Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Has Been DISABLED…" -ForegroundColor Green
            Write-Host ""
        } Else {
            Write-Host ""
            Write-Host "Action Not Confirmed…" -ForegroundColor Yellow
            Write-Host "Nothing Was Changed…" -ForegroundColor Yellow
            Write-Host ""
         }
    } Else {
        Write-Host ""
        Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is DISABLED…" -ForegroundColor Green
        Write-Host "Nothing To Do Here!…" -ForegroundColor Green
        Write-Host ""
    }
} Else {
    Write-Host ""
    Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The INTRANET Is DISABLED…" -ForegroundColor Green
    Write-Host "Therefore, WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is Also DISABLED…" -ForegroundColor Green
    Write-Host "Nothing To Do Here!…" -ForegroundColor Green
    Write-Host ""
}

image

Figure 1: Checking Status Of The WS-Trust ‘2005’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed

Check the status of the WS-Trust ‘13’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed. You can do that through the following PowerShell commands:

Clear-Host
$adfsWSTrust13EndpointPath = "/adfs/services/trust/13/windowstransport"
$adfsWSTrust13 = Get-AdfsEndpoint -AddressPath $adfsWSTrust13EndpointPath
If ($adfsWSTrust13.Enabled -eq $true) {
     Write-Host ""
     Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The INTRANET Is ENABLED…" -ForegroundColor Green
     If ($adfsWSTrust13.Proxy -eq $true) {
         Write-Host ""
         Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is ENABLED…" -ForegroundColor Red
         Write-Host "Due To A Security Vulnerability It Is Highly Recommended To Disable This Endpoint On The Extranet Side Of ADFS!…" -ForegroundColor Red
         Write-Host ""
         $confirmationAdfsWSTrust13 = Read-Host "Do You Want To Disable This Endpoint On The Extranet Side? [Yes|No]"
         If ($confirmationAdfsWSTrust13.ToUpper() -eq "YES" -Or $confirmationAdfsWSTrust13.ToUpper() -eq "Y") {
             Set-AdfsEndpoint -TargetAddressPath $adfsWSTrust13EndpointPath -Proxy $false           
             Write-Host ""
            Write-Host "Action Confirmed…" -ForegroundColor Green
             Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Has Been DISABLED…" -ForegroundColor Green
             Write-Host ""
         } Else {
             Write-Host ""
             Write-Host "Action Not Confirmed…" -ForegroundColor Yellow
             Write-Host "Nothing Was Changed…" -ForegroundColor Yellow
             Write-Host ""
        }
     } Else {
         Write-Host ""
         Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is DISABLED…" -ForegroundColor Green
         Write-Host "Nothing To Do Here!…" -ForegroundColor Green
         Write-Host ""
     }
} Else {
     Write-Host ""
     Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The INTRANET Is DISABLED…" -ForegroundColor Green
     Write-Host "Therefore, WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is Also DISABLED…" -ForegroundColor Green
     Write-Host "Nothing To Do Here!…" -ForegroundColor Green
     Write-Host ""
}

image

Figure 2: Checking Status Of The WS-Trust ‘13’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed

After doing this, you need to restart the ADFS service so that it consumes the configuration change. It is recommended to do this on one ADFS server at a time and not all at the same time. If you have a load balancer, it should determine when the ADFS service is being started, that ADFS server is (temporarily) unavailable. If you do not have a load balancer, you really need to plan this accordingly!

Restart-Services ADFSSRV

Hope this helps you!

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

(2019-07-15) Reenrolling Your Mobile Device

Posted by Jorge on 2019-07-15


the This post is based upon my experience with an iPhone or iPad enrolled in Intune and configured to use the Microsoft Authenticator app. No experience (yet) with an Android device.

Now imagine this, you have enrolled your mobile device (iPhone/iPad) in Intune for MDM and you have installed the Microsoft Authenticator App to support Azure AD MFA (Cloud) for your company account and most likely, or better yet “hopefully” any other account that supports the Microsoft Authenticator App. Looking at myself, when I find a system for which I have an account that supports the Microsoft Authenticator App I configure that account to use it. So far I have added about 70 accounts to the Microsoft Authenticator App.

At device level it has been configured to create a backup of the mobile device (iPhone/iPad) to my iCloud account. At Microsoft Authenticator App level, I also configured it to make backups on a regular basis to my iCloud account.

After using your mobile device (iPhone/iPad) for quite some time, it is either stolen, broken or lost. Solution? Get a new mobile device (iPhone/iPad) and restore it from the iCloud backup.

By restoring it from the an iCloud backup the MDM registration gets wiped, so you will need to register it again. By restoring it from the iCloud backup, the mobile device (iPhone/iPad) inherits the same name from the device from which the backup was created. If you reregister it again, you will end up with an additional device having the same name as the previous one. Now which device can be removed when both the previous and new mobile device have the same name?

After restoring the backup of the Microsoft Authenticator app from the iCloud account, all the accounts in the Microsoft Authenticator app will continue to work, except for any Microsoft-based account (Microsoft Account/Windows Live/Outlook.com/hotmail.com. etc. or Azure AD) as that account needs to be reactivated by re-scanning the QR-code. Just taking the Azure AD account into account, and assuming you are using the converged experience for registering SSPR/MFA security info, you will again end up with 2 registrations (the previous and the new one) having the same name for the mobile device (iPhone/iPad) that has the Microsoft Authenticator app installed.

So to be able to recognize the new mobile device (iPhone/iPad), your best bet as A USER is to change its name after the iCloud restore and before the registration of the mobile device (iPhone/iPad) in Intune and before the re-registration/re-activation of the Azure AD account in the Microsoft Authenticator app for MFA. If you do this and after that re-register in Intune and re-register/re-activate the Azure AD account, you will be able to distinguish the new mobile device (iPhone/iPad) from the old mobile device (iPhone/iPad) and remove the old registration. An admin is able to see the difference in Azure AD of registered devices by looking at for example the registration date and last activity date.

Now, also let’s assume you did not change the mobile device’s (iPhone/iPad) name and you went straight to re-registering it in Intune for MDM and you also re-registered/activated the Azure AD for MFA in the Microsoft Authenticator app. Currently to be able to distinguish the registration of the old and new device for both Intune and Microsoft Authenticator app, that is not possible with changing its name afterwards.

You can do that by following the next steps (based upon my own experience):

Changing name in Intune:

  • Open the Company portal app
  • Sign-out and really close the Company portal app
  • Close the Microsoft Authenticator app
  • Rename mobile device (iPhone/iPad) in iOS
  • Open the Company portal app and sign-in
  • Navigate to the Device section (no need to rename the device name in the Company Portal app itself)
  • Push down for update multiple times until the original name property at the bottom displays the same name as the name you gave it in iOS
  • Also in the Device section, tap “Check Settings” (if you have more than one device registered, select the correct device first)
  • Now if you navigate to the registered devices page (#/device-list">https://myprofile.microsoft.com/?tenant=<tenant ID>#/device-list), you most likely will see the new name of the device. Any mobile device with the old name could be removed from the device list.
  • Delete the registration of the device with the old name(s) for the same mobile device (iPhone/iPad)

Changing name in the registration of the Microsoft Authenticator app in the security info (converged expererience)

  • Navigate to the security info page (">https://mysignins.microsoft.com/security-info?tenant=<tenant ID>)
  • Reregister the Microsoft Authenticator app as a new method (it may be already registered and there is no need to remove it first as you do not know which to remove)
  • Open the Microsoft Authenticator app and readd a Work or School Account, scan the QR-code and complete the registration
  • On the security info page, after reloading it, one of the previous names will have changed to the new name
  • Delete the registration of the Microsoft Authenticator app with the old name(s) for the same mobile device (iPhone/iPad)

Now if you really liked the previous name of the device, just follow the exact same steps above and when you reach the step of renaming the device in iOS, reuse the previous name.

@Microsoft: Please make it easier for users to see differences of old and new registrations in both Intune and Azure AD security info . Add something like a registration date, last activity date, a unique ID that can be easily found in Intune / Security Info, etc. Main reason: empower the user to manage its own info and actually make it easier for them. THANKS!!!

Hope this helps you!

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 Intune, Microsoft Authenticator App, Mobile Devices, Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2019-07-11) Creating A List Of Role Members Within Azure AD Administrative Units

Posted by Jorge on 2019-07-11


Do you need to create a list of role members that have been delegated one or more roles to administrative units? Then look no further. See the example below

image

Figure 3: The Administrative Units And Its Scoped Role Members

The script can be downloaded from the script gallery here.

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 Administrative Units, PowerShell, Tooling/Scripting, Windows Azure Active Directory | Leave a Comment »

(2019-07-09) Creating A List Of Users Within Azure AD Administrative Units

Posted by Jorge on 2019-07-09


Do you need to create a list of users that are a members of administrative units? Then look no further. See the example below

image

Figure 1: The Administrative Units And Its AU Members

The script can be downloaded from the script gallery here.

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 Administrative Units, PowerShell, Tooling/Scripting, Windows Azure Active Directory | Leave a Comment »

(2019-07-07) Azure AD Delegation Through Roles And Administrative Units – The Good, The Bad And The Ugly (Part 2)

Posted by Jorge on 2019-07-07


When I started this quest, my initial thoughts on all this were to delegate the “Reset of the MFA Profile” to other service desks for a scoped list of users in AAD when something happened to the users’ mobile device/phone. That could be: lost, broken or stolen device/phone. With that in mind I tried the following roles “Privileged Authentication Administrator” and “Authentication Administrator”. Before continuing I first read a few things to understand what had changed since the last time I looked at it. I can tell you that was quite some time ago!

In summary I saw the following:

  • Still in preview!
  • Managing Administrative Units and everything around that through PowerShell
  • Requires AzureADPreview Module!
  • Resources can only be users!

My investigation started by first creating some users in AAD that used native AAD Authentication, no federation or anything special like that to keep it as simple as possible. My idea was to create 5 regular users per AU and for each AU also create 1 admin for 4 unique AAD roles. I used the following PowerShell CMDlets:

# Create Users In AAD

$tenantDomain = "<AAD Tenant Domain>" # Replace this with your own value

$mobile = "<Mobile Phone Number>" # Replace this with your own value

$pwdProfileAM = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile

$pwdProfileAM.Password = ‘<Some Text String As Password>‘ # Replace this with your own value

New-AzureADUser -DisplayName "John Doe (AM 1)" -GivenName "John" -Surname "Doe (AM 1)" -PasswordProfile $pwdProfileAM -UserPrincipalName "john.doe.am1@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Finance" -JobTitle "Accountant" -Mobile $mobile -MailNickName "john.doe.am1" -UsageLocation "US"

New-AzureADUser -DisplayName "John Doe (AM 2)" -GivenName "John" -Surname "Doe (AM 2)" -PasswordProfile $pwdProfileAM -UserPrincipalName "john.doe.am2@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Finance" -JobTitle "Accountant" -Mobile $mobile -MailNickName "john.doe.am2" -UsageLocation "US"

New-AzureADUser -DisplayName "John Doe (AM 3)" -GivenName "John" -Surname "Doe (AM 3)" -PasswordProfile $pwdProfileAM -UserPrincipalName "john.doe.am3@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Finance" -JobTitle "Accountant" -Mobile $mobile -MailNickName "john.doe.am3" -UsageLocation "US"

New-AzureADUser -DisplayName "John Doe (AM 4)" -GivenName "John" -Surname "Doe (AM 4)" -PasswordProfile $pwdProfileAM -UserPrincipalName "john.doe.am4@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Finance" -JobTitle "Accountant" -Mobile $mobile -MailNickName "john.doe.am4" -UsageLocation "US"

New-AzureADUser -DisplayName "John Doe (AM 5)" -GivenName "John" -Surname "Doe (AM 5)" -PasswordProfile $pwdProfileAM -UserPrincipalName "john.doe.am5@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Finance" -JobTitle "Accountant" -Mobile $mobile -MailNickName "john.doe.am5" -UsageLocation "US"

New-AzureADUser -DisplayName "Admin Priv AuthN (AM Admin)" -GivenName "Admin" -Surname "Priv AuthN (AM Admin)" -PasswordProfile $pwdProfileAM -UserPrincipalName "admin.priv.authn.am@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Operations" -JobTitle "DevOpsAdmin – PrivAuthN" -Mobile $mobile -MailNickName "admin.priv.authn.am" -UsageLocation "US"

New-AzureADUser -DisplayName "Admin AuthN (AM Admin)" -GivenName "Admin" -Surname "AuthN (AM Admin)" -PasswordProfile $pwdProfileAM -UserPrincipalName "admin.authn.am@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Operations" -JobTitle "DevOpsAdmin – AuthN" -Mobile $mobile -MailNickName "admin.authn.am" -UsageLocation "US"

New-AzureADUser -DisplayName "Admin Helpdesk (AM Admin)" -GivenName "Admin" -Surname "Helpdesk (AM Admin)" -PasswordProfile $pwdProfileAM -UserPrincipalName "admin.helpdesk.am@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Operations" -JobTitle "DevOpsAdmin – Helpdesk" -Mobile $mobile -MailNickName "admin.helpdesk.am" -UsageLocation "US"

New-AzureADUser -DisplayName "Admin User Account (AM Admin)" -GivenName "Admin" -Surname "User Account (AM Admin)" -PasswordProfile $pwdProfileAM -UserPrincipalName "admin.user.account.am@$tenantDomain" -AccountEnabled $true -City "New York" -Country "United States Of America" -Department "Operations" -JobTitle "DevOpsAdmin – UserAccount" -Mobile $mobile -MailNickName "admin.user.account.am" -UsageLocation "US"

$pwdProfileEU = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile

$pwdProfileEU.Password = ‘<Some Text String As Password>‘ # Replace this with your own value

New-AzureADUser -DisplayName "Jan Janssen (EU 1)" -GivenName "Jan" -Surname "Janssen (EU 1)" -PasswordProfile $pwdProfileEU -UserPrincipalName "jan.janssen.eu1@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "ICT" -JobTitle "Engineer" -Mobile $mobile -MailNickName "jan.janssen.eu1" -UsageLocation "NL"

New-AzureADUser -DisplayName "Jan Janssen (EU 2)" -GivenName "Jan" -Surname "Janssen (EU 2)" -PasswordProfile $pwdProfileEU -UserPrincipalName "jan.janssen.eu2@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "ICT" -JobTitle "Engineer" -Mobile $mobile -MailNickName "jan.janssen.eu2" -UsageLocation "NL"

New-AzureADUser -DisplayName "Jan Janssen (EU 3)" -GivenName "Jan" -Surname "Janssen (EU 3)" -PasswordProfile $pwdProfileEU -UserPrincipalName "jan.janssen.eu3@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "ICT" -JobTitle "Engineer" -Mobile $mobile -MailNickName "jan.janssen.eu3" -UsageLocation "NL"

New-AzureADUser -DisplayName "Jan Janssen (EU 4)" -GivenName "Jan" -Surname "Janssen (EU 4)" -PasswordProfile $pwdProfileEU -UserPrincipalName "jan.janssen.eu4@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "ICT" -JobTitle "Engineer" -Mobile $mobile -MailNickName "jan.janssen.eu4" -UsageLocation "NL"

New-AzureADUser -DisplayName "Jan Janssen (EU 5)" -GivenName "Jan" -Surname "Janssen (EU 5)" -PasswordProfile $pwdProfileEU -UserPrincipalName "jan.janssen.eu5@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "ICT" -JobTitle "Engineer" -Mobile $mobile -MailNickName "jan.janssen.eu5" -UsageLocation "NL"

New-AzureADUser -DisplayName "Admin Priv AuthN (EU Admin)" -GivenName "Admin" -Surname "Priv AuthN (EU Admin)" -PasswordProfile $pwdProfileEU -UserPrincipalName "admin.priv.authn.eu@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "Operations" -JobTitle "DevOpsAdmin – PrivAuthN" -Mobile $mobile -MailNickName "admin.priv.authn.eu" -UsageLocation "NL"

New-AzureADUser -DisplayName "Admin AuthN (EU Admin)" -GivenName "Admin" -Surname "AuthN (EU Admin)" -PasswordProfile $pwdProfileEU -UserPrincipalName "admin.authn.eu@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "Operations" -JobTitle "DevOpsAdmin – AuthN" -Mobile $mobile -MailNickName "admin.authn.eu" -UsageLocation "NL"

New-AzureADUser -DisplayName "Admin Helpdesk (EU Admin)" -GivenName "Admin" -Surname "Helpdesk (EU Admin)" -PasswordProfile $pwdProfileEU -UserPrincipalName "admin.helpdesk.eu@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "Operations" -JobTitle "DevOpsAdmin – Helpdesk" -Mobile $mobile -MailNickName "admin.helpdesk.eu" -UsageLocation "NL"

New-AzureADUser -DisplayName "Admin User Account (EU Admin)" -GivenName "Admin" -Surname "User Account (EU Admin)" -PasswordProfile $pwdProfileEU -UserPrincipalName "admin.user.account.eu@$tenantDomain" -AccountEnabled $true -City "Amsterdam" -Country "The Netherlands" -Department "Operations" -JobTitle "DevOpsAdmin – UserAccount" -Mobile $mobile -MailNickName "admin.user.account.eu" -UsageLocation "NL"

After this I had to create some administrative units in AAD. 2 AUs was more than enough

# Create Administrative Units In AAD

New-AzureADAdministrativeUnit -Description "AM Region – City Of New York" -DisplayName "AM Region – NYC"

New-AzureADAdministrativeUnit -Description "EU Region – City Of Amsterdam" -DisplayName "EU Region – AMS"

Before being able to continue and configure things I needed to retrieve the objects that were created in AAD

# Get individual AUs

$auAMNYC = $aUs | ?{$_.Displayname -eq "AM Region – NYC"}

$auEUAMS = $aUs | ?{$_.Displayname -eq "EU Region – AMS"}

# Get List Of Candidate Users Using SOME Filter

$usersAMNYC = Get-AzureADUser -Filter "(City eq ‘New York’)"

$usersEUAMS = Get-AzureADUser -Filter "(City eq ‘Amsterdam’)"

Now I needed to add the previously created users to the previously created AUs

# Add Users To AUs

$usersAMNYC | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    Add-AzureADAdministrativeUnitMember -ObjectId $auAMNYC.ObjectId -RefObjectId $userObjectID

}

$usersEUAMS | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    Add-AzureADAdministrativeUnitMember -ObjectId $auEUAMS.ObjectId -RefObjectId $userObjectID

}

Now I needed to assign the roles to specific admins for specific AUs

# Retrieve Admin Accounts For AM – New York

$adminPrivAuthNAMNYC = Get-AzureADUser -Filter "(City eq ‘New York’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – PrivAuthN’)"

$adminAuthNAMNYC = Get-AzureADUser -Filter "(City eq ‘New York’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – AuthN’)"

$adminHelpdeskAMNYC = Get-AzureADUser -Filter "(City eq ‘New York’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – Helpdesk’)"

$adminUserAccountAMNYC = Get-AzureADUser -Filter "(City eq ‘New York’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – UserAccount’)"

# Retrieve Admin Accounts For EU – Amsterdam

$adminPrivAuthNEUAMS = Get-AzureADUser -Filter "(City eq ‘Amsterdam’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – PrivAuthN’)"

$adminAuthNEUAMS = Get-AzureADUser -Filter "(City eq ‘Amsterdam’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – AuthN’)"

$adminHelpdeskEUAMS = Get-AzureADUser -Filter "(City eq ‘Amsterdam’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – Helpdesk’)"

$adminUserAccountEUAMS = Get-AzureADUser -Filter "(City eq ‘Amsterdam’) and (Department eq ‘Operations’) and (JobTitle eq ‘DevOpsAdmin – UserAccount’)"

# Prepare The Role Definitions And Enable As Needed

# ROLE: Privileged Authentication Administrator

$privAuthAdminRoleDisplayName = "Privileged Authentication Administrator"

$privAuthAdminRole = Get-AzureADDirectoryRole | ?{$_.DisplayName -eq $privAuthAdminRoleDisplayName} # Allowed to view, set and reset authentication method information for any user (admin or non-admin).

If (!$privAuthAdminRole) {

    $privAuthAdminRoleTemplate = $null

     $privAuthAdminRoleTemplate = Get-AzureADDirectoryRoleTemplate | ?{$_.DisplayName -eq $privAuthAdminRoleDisplayName}

    Enable-AzureADDirectoryRole -RoleTemplateId $privAuthAdminRoleTemplate.ObjectId

}

$privAuthAdminRoleObjectID = $privAuthAdminRole.ObjectId

# ROLE: Authentication Administrator

$authAdminRoleDisplayName = "Authentication Administrator"

$authAdminRole = Get-AzureADDirectoryRole | ?{$_.DisplayName -eq $authAdminRoleDisplayName} # Allowed to view, set and reset authentication method information for any non-admin user.

If (!$authAdminRole) {

    $authAdminRoleTemplate = $null

    $authAdminRoleTemplate = Get-AzureADDirectoryRoleTemplate | ?{$_.DisplayName -eq $authAdminRoleDisplayName}

    Enable-AzureADDirectoryRole -RoleTemplateId $authAdminRoleTemplate.ObjectId

}

$authAdminRoleObjectID = $authAdminRole.ObjectId

# ROLE: Helpdesk Administrator

$helpdeskAdminRoleDisplayName = "Helpdesk Administrator"

$helpdeskAdminRole = Get-AzureADDirectoryRole | ?{$_.DisplayName -eq $helpdeskAdminRoleDisplayName} # Can reset passwords for non-administrators and Helpdesk Administrators

If (!$helpdeskAdminRole) {

    $helpdeskAdminRoleTemplate = $null

    $helpdeskAdminRoleTemplate = Get-AzureADDirectoryRoleTemplate | ?{$_.DisplayName -eq $helpdeskAdminRoleDisplayName}

    Enable-AzureADDirectoryRole -RoleTemplateId $helpdeskAdminRoleTemplate.ObjectId

}

$helpdeskAdminRoleObjectID = $helpdeskAdminRole.ObjectId

# ROLE: User Account Administrator

$userAccountAdminRoleDisplayName = "User Account Administrator"

$userAccountAdminRole = Get-AzureADDirectoryRole | ?{$_.DisplayName -eq "User Account Administrator"} # Can manage all aspects of users and groups, including resetting passwords for limited admins

If (!$userAccountAdminRole) {

    $userAccountAdminRoleTemplate = $null

    $userAccountAdminRoleTemplate = Get-AzureADDirectoryRoleTemplate | ?{$_.DisplayName -eq $userAccountAdminRoleDisplayName}

    Enable-AzureADDirectoryRole -RoleTemplateId $userAccountAdminRoleTemplate.ObjectId

}

$userAccountAdminRoleObjectID = $userAccountAdminRole.ObjectId

# Role Delegation For AM – New York

$adminPrivAuthNAMNYC | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auAMNYC.ObjectId -RoleObjectId $privAuthAdminRoleObjectID -RoleMemberInfo $userMemberInfo

}

$adminAuthNAMNYC | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auAMNYC.ObjectId -RoleObjectId $authAdminRoleObjectID  -RoleMemberInfo $userMemberInfo

}

$adminHelpdeskAMNYC | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

     $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auAMNYC.ObjectId -RoleObjectId $helpdeskAdminRoleObjectID -RoleMemberInfo $userMemberInfo

}

$adminUserAccountAMNYC | %{

     $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auAMNYC.ObjectId -RoleObjectId $userAccountAdminRoleObjectID -RoleMemberInfo $userMemberInfo

}

# Role Delegation For EU – Amsterdam

$adminPrivAuthNEUAMS | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auEUAMS.ObjectId -RoleObjectId $privAuthAdminRoleObjectID -RoleMemberInfo $userMemberInfo

}

$adminAuthNEUAMS | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auEUAMS.ObjectId -RoleObjectId $authAdminRoleObjectID  -RoleMemberInfo $userMemberInfo

}

$adminHelpdeskEUAMS | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auEUAMS.ObjectId -RoleObjectId $helpdeskAdminRoleObjectID -RoleMemberInfo $userMemberInfo

}

$adminUserAccountEUAMS | %{

    $userObjectID = $null

    $userObjectID = $_.ObjectId

    $userMemberInfo = $null

    $userMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @{ObjectId = $userObjectID}

    Add-AzureADScopedRoleMembership -ObjectId $auEUAMS.ObjectId -RoleObjectId $userAccountAdminRoleObjectID -RoleMemberInfo $userMemberInfo

}

While adding the “Privileged Authentication Administrator” AAD role I noticed the following

image

Figure 1: An Error Stating That Role Delegation For Administrative Units Is Only Possible For The “User Account Administrator” Role And The “Helpdesk Administrator” Role

Now this is a bummer! Damn!

The end result of all this is:

image

Figure 2: The Administrative Units And Its AU Members

image

Figure 3: The Administrative Units And Its Scoped Role Members

It should be obvious the “Privileged Authentication Administrator” is missing as that one failed as displayed in figure 1. It is weird though the configuration for that one failed, as the configuration for the “Authentication Administrator” role succeeded.

As in the previous post I started with the AAD Portal (https://portal.azure.com/) and I logged on with admin.authn.am@iamtec.onmicrosoft.com which was delegated the “Authentication Administrator” in the “AM Region – NYC” AU. Looking at my own Directory Role I saw the following

image

Figure 4: The Assigned Directory Role To The Admin Account In The Directory Role Section Of The User Account

Although the AAD Portal is able to see that I have the “Authentication Administrator” role assigned, on the main page of the AAD Portal it tells me I’m a regular user

image

Figure 5: The Assigned Directory Role To The Admin Account On The Main Overview Page

So is the AAD Portal having some role crisis regarding this user? Something else worth mentioning is that the AAD Portal unfortunately does not have a notion about AUs, at least I could not see anything about that when logged on with the delegated admin account.

Trying to reset the MFA profile for a scoped user….

image

Figure 6: Authentication Methods Section For A User Through The AAD Portal

Looking at that I see I can do something with the following because it is not greyed:

  • Edit Authentication Info
  • Revoke MFA sessions
  • Require Re-Register MFA
  • Reset Password

This time stuff was not as I expected. Almost everything was greyed out and I got the message that I did not have access to the requested data. In the end I thing that the AAD Portal overview page was indeed right. Just a regular user!

I did try the Password Reset as that was not greyed out, but it failed with an error saying: “The password can not be reset. This may be due to an incorrect level of administrative privilege or if trying to reset your own password

Let’s move on to the Office 365 Admin Center.

I logged on with admin.authn.am@iamtec.onmicrosoft.com and in the “Users – Active Users” section I could only see the users of the administrative unit I was had been assigned a role in. If I was assigned a role for multiple administrative units than the drop-down list would specify all applicable AUs and for each AU the AU members would be displayed below

image

Figure 7: List Of Users Within A Specific Administrative Unit The Admin Was Delegated To

In the Office 365 Admin Center I was not able to find a way to Reset the MFA profile or to revoke MFA sessions. Unfortunately that was disappointing as I was able to reset the password of the scoped users.

Moving to PowerShell using any of the following CMDlets:

Revoke-AzureADUserAllRefreshToken –ObjectId <Object ID Or UPN>

Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName <UPN>

Set-MsolUserPassword -UserPrincipalName <UPN> -NewPassword ‘<Some Text String As Password>’

Set-AzureADUserPassword -ObjectId <Object ID Or UPN> -Password $(ConvertTo-SecureString -String ‘<Some Text String As Password>’ -AsPlainText -Force)

All CMDlets succeeded, except the one that I really needed!

image

Figure 8: Using PowerShell When Using Delegated AAD Roles For Administrative Units

As it looks, there appears to be no way in delegating the reset of an MFA profile for a scoped user. The AAD Portal does not really understand administrative Units, The O365 Admin Center does understand administrative Units, but has no option to reset the MFA profile for a scoped user when using AUs. Through PowerShell, the CMDlet “Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName <UPN>” does not work when using delegated permissions for AUs.

Not much has changed unfortunately. As how I look at it right now, although it does support delegated tasks in the Office 365 Admin Center, it lacks the options to be able to do everything. With this in mind the administrative units feature is not yet enterprise ready, especially when the need exists to delegate parts to other regions/locations.

Hopefully Microsoft changes this soon

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

(2019-07-04) Azure AD Delegation Through Roles And Administrative Units – The Good, The Bad And The Ugly (Part 1)

Posted by Jorge on 2019-07-04


Within Active Directory (AD), organizational units (OUs) were used to apply policy and delegate administration. With regards to delegation of administration in AD, that came down to delegation of specific actions such as for example “Password Reset” (a so called Control Access Right (CAR)) or Read/Write of a specific attribute such as for example givenName. AD does not know the concept of roles. Those can be implement though by creating a security group that has one or more permissions for a specific scope of objects.

Azure Active Directory (AAD) in turn does not implement OUs like AD, but rather administrative units (AUs). Also, in AAD it is not possible to apply permissions as granular as is possible in AD. Nevertheless, AAD does know the concept of roles and every role has a predefined set of permissions. Some roles are available by default and ready to use and other roles need to be enabled/activated first. Within AAD you can make people permanent members of one or more roles, or when using roles together with Privileged Identity Management (PIM), you can make people eligible of specific roles and allow those eligible people to activate a specific role for a specific amount of time as needed.

Through the following CMDlet you can retrieve the current enabled AAD roles:

Get-AzureADDirectoryRole

In any AAD tenant the following AAD roles are by default enabled:

image

Figure 1: Default Enabled Azure AD Roles

Before you can assign an AAD role through PowerShell it must be enabled first through the following CMDlet:

Enable-AzureADDirectoryRole -RoleTemplateId <Role Template Object ID>

The available roles can be retrieved by asking for the available role templates and can be done through:

Get-AzureADDirectoryRoleTemplate

In any AAD tenant the following AAD role templates are by default available:

image

Figure 2: Default Available Azure AD Role Templates

However, in the AAD Portal (https://portal.azure.com/), it is not required to enable an AAD role first before being able to assign it to someone. As soon as you assign the AAD role through the AAD Portal it is enabled automatically if it was previously disabled. From an AAD portal perspective things look as displayed in the figure below. All AAD roles with a flag, are newly introduced roles.

image

Figure 3: Default Available Azure AD Role (Templates) In The AAD Portal

When using the Office 365 Admin Center (https://portal.office.com/) you can see a similar list with AAD roles that in addition also mention the category the AAD role is used in. Examples are “Identity”, “Security & Compliance”, “Devices”, “Billing”, “Collaboration” and some others.

Looking at the contents of figure 1 and compare it with the contents of figure 2 you can see a huge difference in AAD roles that have been added by Microsoft to AAD to prevent and offload the usage of the “Global Administrator” (a.k.a. “Company Administrator”) and use a less powerful AAD role to accomplish what you need. All AAD roles work at tenant level, so delegating stuff to a less powerful role is progressing by experience and what admins of AAD request. For example, not so long ago I requested Microsoft to implement a new role similar to “Global Administrator” in read-only mode. I have had and still have many occasions where I need “Global Administrator” role just to look a configurations and/or data. Having a “Global Administrator Read-Only” (or whatever Microsoft will call it in the end) would prevent me from having to use the “Global Administrator” role, which is of course a good thing. That way I could be a permanent member of “Global Administrator Read-Only” and use PIM to activate the “Global Administrator” as really needed!. And believe it or not, Microsoft can deprecate roles in AAD as specified in Administrator role permissions in Azure Active Directory at the bottom of the article.

Using the “administrative units” feature in AAD. Unfortunately that’s when things become more problematic and unfortunately experience today is not always consistent. As an example, I’m going to use the “Authentication Administrator”, which has a description of “Allowed to view, set and reset authentication method information for any non-admin user.”. That role will be assigned to the user account “admin.authn.am@iamtec.onmicrosoft.com” at either tenant level or AU level, depending on what I’m discussing.

First, let’s have a look at that role. The “Authentication Administrator” AAD role has a description of “Allowed to view, set and reset authentication method information for any non-admin user.”. Looking at the additional information as written in Administrator role permissions in Azure Active Directory it says:

Users with this role can set or reset non-password credentials. Authentication Administrators can require users to re-register against existing non-password credential (for example, MFA or FIDO) and revoke remember MFA on the device, which prompts for MFA on the next sign-in of users who are non-administrators or assigned the following roles only:

  • Authentication Administrator
  • Directory Readers
  • Guest Inviter
  • Message Center Reader
  • Reports Reader

I have assigned the “Authentication Administrator” AAD role to the user “admin.authn.am@iamtec.onmicrosoft.com” at tenant level. So, what is described above that user can do against ANY non-admin user in AAD and members of the specified AAD roles.

Taking the targeted user “john.doe.am1@iamtec.onmicrosoft.com” as an example, after navigating to that user in the AAD Portal, I see the following in the “Authentication Methods” section of that user.

image

Figure 4: Authentication Methods Section For A User Through The AAD Portal

Looking at that I see I can do something with the following because it is not greyed:

  • Edit Authentication Info
  • Revoke MFA sessions
  • Require Re-Register MFA
  • Reset Password

Everything looks as expected, except for “Reset Password” because the description explicitly mentions “non-password credential”. After trying it, and yes I was able to reset the password of that account while I did not expect to be able to do so. Weird. Probably a bug, but hey it is still in public preview!

Going to the Office 365 Admin Center, I see:

SNAGHTML155ffe81

Figure 5: The Properties For A User Through The O365 Admin Center

In that portal I cannot find a way to require re-registration of MFA or revoke MFA sessions, but I can reset the password.

Trying actions through PowerShell using any of the following CMDlets also work:

Revoke-AzureADUserAllRefreshToken –ObjectId <Object ID Or UPN>

Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName <UPN>

Set-MsolUserPassword -UserPrincipalName <UPN> -NewPassword ‘<Some Text String As Password>’

Set-AzureADUserPassword -ObjectId <Object ID Or UPN> -Password $(ConvertTo-SecureString -String ‘<Some Text String As Password>’ -AsPlainText -Force)

Microsoft is really putting a lot of effort in offloading the usage of the “Global Administrator” AAD role to other less powerful AAD roles. This is really a good thing and I can imagine that’s a lot of work due to all the possible AAD roles people can think of for all the richness that AAD has to offer!

Next time, I’ll continue with this and focus more on administrative units

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

(2019-07-01) Re-Awarded for the 14th Time – MVP Enterprise Mobility (Identity And Access)

Posted by Jorge on 2019-07-01


Oops, I did it again! Smile

Today 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 fourteenth time I have received this award! Smile

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

image

Roughly translated Microsoft is writing:

Dear Jorge de Almeida Pinto,
Once again we are pleased to present the 2019-2020 Microsoft Most Valuable Professional (MVP) Award in recognition of your extraordinary leadership in technical communities. We appreciate your outstanding contributions in the following technical communities in the past year:
• Enterprise Mobility

14x  image_thumb2_thumb_thumb_thumb_thumbJorge de Almeida Pinto photo

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

(2019-05-31) Cloud-Based Azure AD MFA Notifications Not Working While You Already Registered

Posted by Jorge on 2019-05-31


After registering your security info in Azure AD, it may look like or be similar to:

REMARK: the security page looks like this because I have converged experience for MFA and SSPR enabled in AAD

image

Figure 1: Security Information In AAD To Be Able To Use MFA And SSPR (Converged Experience)

Now after navigating to an ADFS connected application and choosing the cloud-based Azure AD MFA on the MFA choice screen in ADFS, you may see a screen telling you the method is not available. In my ADFS it looks like displayed below.

REMARK: this has been customized by me. In a future blog post I will show how

image

Figure 2: (Custom) Error In ADFS Saying That The Account Is Not Registered For The Chosen MFA Method

The weird thing here is that you can see in figure 1 that the account is registered, but for some reason it is still failing as shown in figure 2. I know what the problem is and how to solve it, but do not understand why or when it happens. Although I have the Microsoft Authenticator app registered, you can also see the default sign-in method is set to “Phone – Text”. THAT may work when using SSPR, but in my case it will not work for MFA because I have “Text message to phone” disabled in the Multi-Factor Authentication service settings as displayed below.

image

Figure 3: The Configured Multi-Factor Authentication Service Settings In My AAD Tenant

To cut a long story and a long time of searching for a solution short, you can do the following to solve this.

  1. Navigate to https://aka.ms/setupsecurityinfo
  2. If on the right of the Default Sign-In Method you see a link called “Change”, then click that and skip steps 3 and 4 and 5
  3. If on the right of the Default Sign-In Method you DO NOT see a link called “Change”, then click on “Change” next to “Delete” for the Phone registration
  4. Just reregister the exact same (mobile) phone number. For confirmation you will receive a text message and you need to enter the code received to complete the process
  5. If on the right of the Default Sign-In Method you see a link called “Change”, then click that. If you do not, the go to step 7
  6. Change the default sign-in method to “Authenticator App – Notifications” (assumes you have a registration for the Microsoft Authenticator App)
  7. If MFA still does not work, then navigate to https://aka.ms/setupsecurityinfo and re-register the Microsoft Authenticator app with the account you used to log into AAD. There is no need to remove any existing registration in AAD or the account from the Microsoft Authenticator app. Any new registration will overwrite the existing registration.
  8. If on the right of the Default Sign-In Method you see a link called “Change”, then click that and choose the “Microsoft Authenticator App – Notification” method as the default sign-in method
  9. Try MFA again. It should work now.

The security information should look like or be similar to

image

Figure 4: Security Information In AAD To Be Able To Use MFA And SSPR (Converged Experience)

What I have seen is that after people register the Microsoft Authenticator app in the Security Information page in AAD, for many of them the default sign-in method is automatically changed to “Microsoft Authenticator App – Notifications”, but for some it remains with “Phone – Text”

Enjoy and have fun!,

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

 
%d bloggers like this: