Azure AD Connect SSO

New Contributor

O365 office, 30 users, been on O365 for 3 years. Life is great. 

When I set up O365, I just created new users in the cloud and implemented hyper secure passwords informing my users they would no longer have to change them every 90 days. (10 characters at least, Cap+Num+Sym). So we've had on prem and cloud accounts. No big deal, same passwords, everything is fine. Yea, you have to renenter passwords some times but my users were fine with it.  

Now I want to end this and do SSO. I've been hemming and hawing about this for weeks. 

A few questions:

  • Every single thing I read "Make sure you install this on 2 servers for redundancy". I only have one 2012 server. Since I started here 8 years ago we have been shutting servers down, not adding more. We had 4 when I started 8 years ago. Today we have 2 but the 2nd is a 2003 server that ONLY handles DNS and basically backs up the 2012. But connect won't run on that. And I plan to shut that down 1Q 2020. Thoughts on that?
  • According to this: If you uninstall a Pass-through Authentication Agent from a server, it causes the server to stop accepting sign-in requests. To avoid breaking the user sign-in capability on your tenant, ensure that you have another Authentication Agent running before you uninstall a Pass-through Authentication Agent. I want to test this today on my computer today. If I don't like it or something doesn't work I cannot go back without a different AA in place? It just won't start working again like it does right now? 
  • Am I missing anything else?

Am I overthinking this? (I'm sure I am, I am overly protective of my infrastructure). 

4 Replies

Hi @AliceChained,


To have SSO and you do not want to have on-premises servers, you can do it with Azure Active Directory Domain Services, bellow are some link's about your scenario.


Best regards,

Nuno Árias Silva

@AliceChained Hi

You are fine with one AD Connect server. If your server dies, you will have lost the whole of AD which will be more of an issue. Assuming you can recover your on-prem AD, then you will just be able to reinstall AD connect and it will carry on syncing as before. So don't worry about that.

What you need to be more careful of is making sure that AD connect will correctly match up on-prem users with existing cloud users. You don't want to end up with duplicates. This is called soft matching, basically the UPN and primary SMTP address (proxyaddress) need to match, see for more info.


Finally, how are you going to manage email attributes when you are in sync? You may not know that once users are synced from your AD, all email attributes have to originate in your AD (it won't let you do this in Exchange Online any more). You have 2 options:

1. Use AD Users and Computers attribute editor to edit proxyaddresses. This is unsupported however.

2. Install a free Exchange server which is just used for managing user attributes. For Office 365 plans you get a free Exchange Server Hybrid Key:

@Nuno Silva Thank you for that. Still reading those. I'm absolutely not opposed to keeping one server in house, though. I certainly still do need a Print server for the forseeable future. 


@CloudHal Ha. Great point about only one server. Thanks for that.

I read that existing Tenant document already. I've been reading and researching this for some time. 

My on prem UPN has set to the FQDN for some time. That was one of my biggest fears, duplicate users or breaking existing email accounts.    

Re: managing attributes. Wait wait wait... what? Ok, this is the first I've heard that I should install... an Exchange server?!? Did I mention I've been reading and researching this for a while?!? And AD Users & C is... unsupported? What? WHAT? I can't wrap my head around MS not supporting that method. ha. 

I'm not screwing around with a server just to do that. The day I decommissioned my Exchange server was a happy day. lol So without a server, do I have to CREATE new users in ADSIEdit too?   


@AliceChained yes this is a surprise to a lot of people...basically as soon as you are syncing from on-prem AD, you have to manage email attributes in your on-prem AD (otherwise you would not be able to add secondary SMTP address for example), and currently, the only supported way of doing that is using Exchange.


If you do not want to do that, you can just create users in AD as normal, and us AD users & Computers (Advanced view - attribute editor) to define the SMTP addresses (in the proxyaddress attribute). Check out this page:

'The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange admin center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects. '