29 January 2021

Single Sign On broken - Azure Active Directory Seamless Single Sign-On

 I don't know if this is something that only happens in my environment, but it happens.

When ever I start AADConnect and make a change in the configuration, add an OU for example, and save the change SSO breaks.

Quick way to see what's up is here:


If there are zero Seamless single sign-on domain's than you know what's up.
The SSO trust is broken.

There is a blogpost on docs.microsoft.com about it:
Azure Active Directory Connect: Troubleshoot Seamless Single Sign-On | Microsoft Docs

The steps listed there are in this script below.

Run this from the AADConnect machine:

# https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso            
            
# Import the Seamless SSO PowerShell module            
cd \            
cd 'C:\Program Files\Microsoft Azure Active Directory Connect'            
Import-Module .\AzureADSSO.psd1            
# Get the list of Active Directory forests on which Seamless SSO has been enabled            
New-AzureADSSOAuthenticationContext            
Get-AzureADSSOStatus            
#Disable Seamless SSO for each Active Directory forest where you've set up the feature            
$creds = Get-Credential domain\username            
Disable-AzureADSSOForest -OnPremCredentials $creds            
# Enable Seamless SSO for each Active Directory forest            
Enable-AzureADSSOForest            
# Enable the feature on your tenant            
Enable-AzureADSSO -Enable $true

11 January 2021

problem 4003 (INSUFF_ACCESS_RIGHTS)

When I tried to change a mailbox from type "User mailbox" to type "Shared mailbox" I got this error:

[PS] C:\>Set-Mailbox mailboxalias -Type shared -force

Error on proxy command 'Set-Mailbox -Type:'Shared' -Identity:'mailboxalias' -Confirm:$False -Force:$True' to server servername.domain.lan: Server version 15.00.1497.0000, Proxy method RPS:

Active Directory operation failed on servername.domain.lan. This error is not retriable. Additional information: Insufficient access rights to perform the operation.

Active directory response: 00002098: SecErr: DSID-03150F93, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

+ CategoryInfo          : NotSpecified: (:) [Set-Mailbox], CmdletProxyException
+ FullyQualifiedErrorId : Microsoft.Exchange.Configuration.CmdletProxyException,Microsoft.Exchange.Management.RecipientTasks.SetMailbox
+ PSComputerName        : servername.domain.lan

Turns out this has to do with user rights inheritance, find the user, select the "Security" tab and click the "Advanced" button.

There you should see the "Enable inheritance" button. Click it and wait for Active Directory synchronization.


Now when you run the same commandlet again, you should see no output, and thus the command worked. To double check you could run:

Get-Mailbox mailboxalias | Select RecipientTypeDetails

07 January 2021

550 5.7.520 Access denied & 550 5.4.142 RESOLVER.FWD.LoopingTarget

Since a couple of months Office365 and Exchange Online are blocking the auto forwarding of email to external domains.

And this is the error that can be found in the message trace results:

Error: 550 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555)

While this is a good idea in general, sometimes you want to enable it.

Here's how:

Go to https://protection.office.com/antispam

And create a new outbound policy.

Give it a name, description, decide whether you to be notified or not and if you want to apply recipient limits with an action if the limits are exceeded.

The the following is important.
At the automatic forwarding choose "On - Forwarding is enabled".
Choosing "Automatic - System-controlled" will not let the email be sent. This is the setting for the default policy "Outbound spam filter policy ‎(always ON)‎".

Then add a condition at "Applied to".

The easiest condition is to create a mail enabled security group that holds all the user accounts that you want to grant this right.


If you add 2 conditions, such as a security group and a separate user then you will receive this error in the message trace results:

Reason: [{LED=550 5.4.142 RESOLVER.FWD.LoopingTarget; forwarding to a looping external address};{MSG=};{FQDN=};{IP=};{LRT=}]


05 January 2021

When was the last time you reset the password of the AzureADSSOACC account?

 When was the last time you reset the password of the AzureADSSOACC account?


$user = [adsi]"LDAP://CN=AzureADSSOACC,CN=Computers,DC=yourdomain,DC=lan"            
[PSCustomObject] @{            
name = $user.name.Value            
pwdLastSet = [datetime]::FromFileTime($user.ConvertLargeIntegerToInt64($user.pwdLastSet.            
value))            
}