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!

Archive for the ‘Windows Azure Active Directory’ Category

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

Advertisements

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-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 »

(2019-05-22) Some Basic Steps For Troubleshooting PRTs

Posted by Jorge on 2019-05-22


In Windows 10 currently there are 2 PRTs:

  • The Azure AD Primary Refresh Token
  • And the Enterprise Primary Refresh Token, a.k.a. the ADFS Primary Refresh Token

For both the following troubleshooting steps apply if you are experiencing issues somehow:

  • Always check the output of: DSREGCMD.EXE /STATUS
  • Event Logs to check on the client:
    • “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log
    • “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log
  • Any correlation ID in any event related to the error experienced on the client, can most like also be found at server side in the corresponding event log. If server side is AAD, then you need Microsoft. If server side is ADFS, then you can check it yourself
  • Changing or resetting the password, invalidates the current PRTs and fresh ones are retrieved/generated
  • If a PRT is missing, triggering to try to retrieve a PRT can be done by either logoff/logon or lock/unlock

With this information you should have a good start to try troubleshooting PRT related issues, although not always easy!

Do not forget to also read Jairo’s blog post about how SSO works in Windows 10

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 Active Directory Federation Services (ADFS), Azure AD PRT, Enterprise PRT, Windows Azure Active Directory | Leave a Comment »

(2019-05-16) Azure AD Connect v1.3.21.0 Has Been Released

Posted by Jorge on 2019-05-16


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.

IMPORTANT

There is a known issue with upgrading Azure AD Connect from an earlier version to 1.3.21.0 where the O365 portal (https://admin.microsoft.com/AdminPortal/Home#/dirsyncmanagement) does not reflect the updated version even though Azure AD Connect upgraded successfully.

To resolve this you need to import the AdSync module and then run the Set-ADSyncDirSyncConfiguration powershell cmdlet on the Azure AD Connect server. You can use the following steps:

  1. Open Powershell in administator mode
  2. Run Import-Module "ADSync"
  3. Run Set-ADSyncDirSyncConfiguration -AnchorAttribute ""

REMARK: Below you can see the last directory sync and the last password sync occurred a few days ago and it is issuing a warning. The reason for that is that I turned my VMs off as I was not using them for a few days

image

Figure 1: Dir Sync Status In The Office Portal

Download "Microsoft Azure Active Directory Connect"

Azure AD Connect: Version Release History

1.3.21.0

Released: 05/14/2019

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

  • N.A.

Fixed issues

  • Fixed an elevation of privilege vulnerability that exists in Microsoft Azure Active Directory Connect build 1.3.20.0. This vulnerability, under certain conditions, may allow an attacker to execute two powershell cmdlets in the context of a privileged account, and perform privileged actions. This security update addresses the issue by disabling these cmdlets. For more information see security update.

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

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

(2019-04-30) Azure AD Connect v1.3.20.0 Has Been Released

Posted by Jorge on 2019-04-30


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"

IMPORTANT: I upgraded from Azure AD Connect 1.2.70.0. As mentioned below in the “New Features And Improvements” section it upgrades a group sync rule to include additional transformations (flows). To be more specific it updates the sync rule called “In from AD – Group Common”. If you have this rule enabled it will most likely perform a full sync for at least the AD connector the next time it syncs after the AAD Connect upgrade. If you have this rule enabled disabled, that means you have a cloned version of it that requires updating if you need those additional transformations (flows) to support group claims in AAD. If you do update that cloned version, then it will most likely perform a full sync for both the AD connector the next time it syncs after the AAD Connect upgrade. Since that may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

However, to my surprise it did not trigger the expected full sync for the AD connector. That was weird, because when sync rules are updated all data needs to be reevaluated, whether or not it has changed. In my case I triggered the full sync myself by running the Run Profiles manually for both the AD Connector and the AAD Connector. The order was: Disable Sync Scheduler, Delta Import for AD Connector, Full Sync for AD Connector, Export for AAD Connector, Delta Import for AAD Connector, Delta Sync for AAD Connector, Export for AD Connector and Re-enable Sync Scheduler.

Azure AD Connect: Version Release History

1.3.20.0

Released: 04/24/2019

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

New Features And Improvements

  • Add support for Domain Refresh
  • Exchange Mail Public Folders feature goes GA
  • Improve wizard error handling for service failures
  • Added warning link for old UI on connector properties page.
  • The Unified Groups Writeback feature is now GA
  • Improved SSPR error message when the DC is missing an LDAP control
  • Added diagnostics for DCOM registry errors during install
  • Improved tracing of PHS RPC errors
  • Allow EA creds from a child domain
  • Allow database name to be entered during install (default name ADSync)
  • Upgrade to ADAL 3.19.8 to pick up a WS-Trust fix for Ping and add support for new Azure instances
  • Modify Group Sync Rules to flow samAccountName, DomainNetbios and DomainFQDN to cloud – needed for claims
  • Modified Default Sync Rule Handling – read more here.
  • Added a new agent running as a windows service. This agent, named “Admin Agent”, enables deeper remote diagnostics of the Azure AD Connect server to help Microsoft Engineers troubleshoot when you open a support case. This agent is not installed and enabled by default. For more information on how to install and enable the agent see What is the Azure AD Connect Admin Agent?.
  • Updated the End User License Agreement (EULA)
  • Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.
  • Added an Azure AD trust management task that provides two options: analyze/update trust and reset trust.
  • Changed the AD FS Azure AD Relying Party trust behavior so that it always uses the -SupportMultipleDomain switch (includes trust and Azure AD domain updates).
  • Changed the install new AD FS farm behavior so that it requires a .pfx certificate by removing the option of using a pre-installed certificate.
  • Updated the install new AD FS farm workflow so that it only allows deploying 1 AD FS and 1 WAP server. All additional servers will be done after initial installation.

Fixed issues

  • Fix the SQL reconnect logic for ADSync serviceFix to allow clean Install using an empty SQL AOA DB
  • Fix PS Permissions script to refine GWB permissions
  • Fix VSS Errors with LocalDB
  • Fix misleading error message when object type is not in scope
  • Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly conflict with Azure AD Connect.
  • Fixed PHS bug on Staging Server when Connector Credentials are updated in the old UI.
  • Fixed some memory leaks
  • Miscellaneous Autoupgrade fixes
  • Miscellaneous fixes to Export and Unconfirmed Import Processing
  • Fixed a bug with handling a backslash in Domain and OU filtering
  • Fixed an issue where ADSync service takes more than 2 minutes to stop and causes a problem at upgrade time.

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

…And just to get ahead of things when needed I also installed the Azure AD Connect Admin Agent in a disabled state. By the way, as mentioned in the documentation, you will be prompted multiple times (about 5x or so) for credentials. So, don’t freak out thinking it is not working.

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

(2018-12-30) Azure AD Connect v1.2.70.0 Has Been Released

Posted by Jorge on 2018-12-30


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.2.70.0

Released: 12/18/2018

Released for download

Prerequisites for Azure AD Connect

More information about Azure AD Connect

Fixed issues

  • This build updates the non-standard connectors (for example, Generic LDAP Connector and Generic SQL Connector) shipped with Azure AD Connect. For more information on applicable connectors, see version 1.1.911.0 in Connector Version Release History.

I (finally) ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle!

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

 
%d bloggers like this: