Change ADconnect to disable Alternate Login ID

[Stefan Baumgarten]

Good morning. We have a client that implemented ADConnect using Alternate Login ID because he was unwilling to change. Now after he recognized the drawbacks he changed the UPN. Now my question is can I easily change ADConnect and ADFS back to use the standard UPN mapping or do I have to completely remove the existing connection. If so, what will this do to the 120 migrated mailboxes, etc.?

[#2]

Hi Stefan,

If I understand correctly then the required settings for UPN are set as well (@contoso.com) and you should be able to disable the alternate ID by running the following command:

Set-AdfsClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL

No additional settings are needed for ADConnect when disabling the Alternate ID.

See also https://technet.microsoft.com/en-us/library/dn659436.aspx 

[#3]

Hi Mike,

sorry to bring this threat up again. I am not only talking about the ADFS part but mainly the Azure AD Connect setting which can only be specified during initial installation as it seems. Any idea?

Stefan

[#4]

Hi Stefan,

AD Connect uses a couple of ways to mactch users from AD with AAD, even when reinstalling the product it tries to match users again with users that already have been synced previously. This is usually done with the immutable ID from AD which is by default the ObjectGUID as SourceAnchor from AD. If you need to change the setup then I would recommend to uninstall AD Connect competely and then reinstall it using the needed settings. Be sure to first check the current configuration first and verify that the ObjectGUID is indeed the SourceAnchor.

If that is the case then you can proceed and uninstall AD Connect, then reinstall it again and select the needed Login ID settings. 

[#5]

Good morning, thanks for the reply, I have just received same information from MS, no way tro change afterwards, plainly need to reinstall or use a second AD Connect machine and use staging to change. Will keep u posted ones completed, will need to evaluate first as we are in production already :(

[#6]

Hi Stefan,

If you are in production and want to make sure that you are not running into issues then I suggest that you first check the current source anchor as I mentioned in my earlier post. If that is ObjectGUID and you don't want to have any downtime then you could spin up a VM either on Azure or locally and install AD Connect on it. Run the installer (make sure to also use the ObjectgUID as a source anchor)  and be sure not to run a sync at the end. When users are not connected (for example tonight) then run a sync from the newly installed machine. Check the results. If all is fine then you can either choose to keep using this installation or rerun the same process on the production AD Connect machine. If all is not fine then stop the newly installed machine and run a full sync from your production AD Connect machine to restore the current setup.

[#7]

source anchor will not change and will still be the objectguid - I condier using a staging adconnect server to test those changes and then switch over to this one if synchronisation is fine