Just can't get enough of IT

Azure AD Pass-through authentication (PTA) recommends that you run at least three authentication agents to provide high availability for authentication. 

When you download and install the PTA agent, registering the PTA agent to Azure AD might fail. This happens most of the time when the network connectivity to Azure AD requires the use of a proxy server. In such a network setup you normally encounter configuration errors only, if the proxy server is misconfigured or the Internet Explorer zone configuration is missing required entries for trusted sites.

When you encounter an error during installation and registration of the dedicated PTA agent I recommend to separate these two steps. You need the credentials of an Azure AD account that is a member of the Global Administrator management group.

1. Download the most current release of the PTA agent: https://aka.ms/getauthagent
2. Copy the downloaded file to the server that will serve as a PTA agent
3. Open an administrative command prompt and install the PTA agent software in silent mode without registering the agent:

AADConnectAuthAgentSetup.exe REGISTERCONNECTOR="false" /q

4. Open an administrative PowerShell session, navigate to the default installation location and register the PTA agent manually

# navigate to the default installation location
cd "C:\Program Files\Microsoft Azure AD Connect Authentication Agent"

# enter the global admin credentials
$cred = Get-Credential

# register the PTA agent using the RegisterConnector.ps1 script
# multiline example
.\RegisterConnector.ps1 `
-ModulePath "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\" `
-ModuleName "PassthroughAuthPSModule" `
-AuthenticationMode Credentials ` 
-UserCredentials $cred `
-Feature PassthroughAuthentication

# single line example
.\RegisterConnector.ps1 -ModulePath "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\" -ModuleName "PassthroughAuthPSModule" -AuthenticationMode Credentials -UserCredentials $cred -Feature PassthroughAuthentication

The Azure AD Pass-through agent Quickstart documentation has an example for automating the installation of the PTA agent as part of a server provisioning process. The current example references the wrong PowerShell module named AppProxyPSModule. The most recent release of the PTA agent does not contain a PowerShell module by that name. Use the PowerShell module PassthroughAuthPSModule, as shown in the PowerShell example shown above.

Links

• Azure Active Directory Pass-through Authentication: Quickstart
• Hybrid Identity Required Ports and Protocols

Enjoy Azure AD!

Description

When using this PowerShell script you can update the guest user's thumbnail photo to a photo that aligns with your company's corporate identity and compliance guidelines, and you do not have to rely on the Azure AD default photo.

• This script sets the AzureADThumbnailPhoto for guest users to a photo provided as JPG or PNG file.
• The photo file can be up to 100KB in size. This is currently not checked in the script.
• You can either update a single guest user or all guest users.
• When updating the user photo can choose to set the photo forcibly or only if there is no photo set.
• The changes are written to a log file. The log file functions are part of the GlobalFunctions module.

Examples

# EXAMPLE
# Set the photo ExternalUser.png for all guest users if no photo exists

.\Set-GuestUserPhoto.ps1 -FilePath D:\Photos\ExternalUser.png -GuestUsersToSelect All -UpdateMode SetIfNoPhotoExists

# EXAMPLE
# Set the photo ExternalUser.png for guest user JohnDoe@varunagroup.de if no photo exists

.\Set-GuestUserPhoto.ps1 -FilePath D:\Photos\ExternalUser.png -GuestUsersToSelect Single -UserPrincipalName JohnDoe@varunagroup.de

Version History

• 1.0, Initial community release

Links

• Download and follow at Github: https://github.com/Apoc70/Set-GuestUserPhoto
• Download and like at TechNet Gallery: https://gallery.technet.microsoft.com/Set-Thumbnail-Photos-for-ae2d437c

Follow

• Twitter @stensitzki
• LinkedIn
• Xing

Problem

You can block an user from logging on to Office 365 by setting the BlockCredential attribute to $true.

Set-MsolUser -UserPrincipalName myuser@mcsmemail.de -BlockCredential $true

But the MSOL user attribute is reverted to $false, when ADD Connect synchonization cycle runs.

This happens, because the local Active Directory attribute accountEnabled is used to controll the BlockCredential attribute in Azure AD.

Solution

If your IT operation requires the ability to have enabled users in your local Active Directory infrastructure and you need to prevent logon to cloud services you need to prevent the accountEnabled attribute from being synchronized to Azure AD. This might not necessarily be a general requirement during normal operations, but might be useful while doing a Proof-of-Concept.

Just exclude the attribute from the Azure Active Directory connector in the Synchronization Service Manager.

The following script disables all users excluding

• Users following a specific naming pattern
• Users listed in a string array

# Userfilter
$UserExceptions = ("Sync_SYNC01_add98768492f@mcsmemail.onmicrosoft.com","SPO-SRV-ACCOUNT@mcsmemail.de","SynchedAdmin@mcsmemail.de")

# Fetch synchronized users 
$DomainAccounts = Get-MsolUser -EnabledFilter EnabledOnly -MaxResults 5000 | Where-Object -Property LastDirSyncTime -ne $null

# Select synchronized users not following the pattern ADM*@mcsmemail.de (admin accounts in this case)
$DomainAccountsWithoutAdmins =  $DomainAccounts | Where-Object -Property UserPrincipalName -notlike "ADM*@mcsmemail.de"

# Exclude accounts listed in $UserExceptions
$DomainAccountsWithoutAdminsFiltered = $DomainAccountsWithoutAdmins | Where-Object -Property UserPrincipalName -NotIn $UserExceptions
 

# Now block cloud logon for all filtered users
ForEach ($User2Block in $DomainAccountsWithoutAdminsFiltered) {
  Write-Host ('Disabling User: {0}.UserPrincipalName)' -f $User2Block)
  Set-MsolUser -UserPrincipalName $User2Block.UserPrincipalName -BlockCredential $true
}

Enjoy Office 365.

Description

Using this script you can test the domain availability in Office 365 and Azure AD. As there are different closed Office 365 and Azure AD regions you need to test per dedicated closed Office 365 region.

Regions currently implemented:

• Global
  This is the default public Office 365 cloud
• Germany
  This is the dedicated Germany Cloud offering aka Office 365 Germany
• China
  This is the Office 365 region hosted by VIANET21

The script queries the login uri for the selected Office 365 region.

The response contains metadata about the domain queried. If the domain already exists in the specified region the metadata contains information if the domain is verified and/or federated.

 Load function into your current PowerShell session:

. .\Test-DomainAvailability.ps1

Examples

# EXAMPLE
# Test domain availability in the default region - Office 365 Global

Test-DomainAvailability -DomainName example.com 

# EXAMPLE
# Test domain availability in Office 365 China    

Test-DomainAvailability -DomainName example.com -LookupRegion China

Version History

• 1.0, Initial community release

Links

• Download and follow at Github: https://github.com/Apoc70/Test-DomainAvailability
• Download at TechNet Gallery: https://gallery.technet.microsoft.com/Test-Office-365Azure-AD-5301c105

Additional Credits

Original source: https://blogs.technet.microsoft.com/tip_of_the_day/2017/02/16/cloud-tip-of-the-day-use-powershell-to-check-domain-availability-for-office-365-and-azure/

Follow

• Twitter @stensitzki
• LinkedIn
• Xing