Questions around managing Directory Synchronization to all of the various cloud services.

  • 324 Views
  • Last Post 01 June 2016
BrianB posted this 31 May 2016

All:   I am looking for suggestions and examples of what people are doing to manage all of the different Directory Synchronizations that need to occur for all of the different cloud vendors that require sync from on-prem AD. For instance, we have multiple cloud vendors that require some sort of Dirsync along with SSO (ADFS, Ping Federate, or proprietary). It seems that every cloud service from small to large wants to sync with on-prem AD. Given the potential number of these different DirSync’s that need to be installed and managed, what are other institutions doing to manage them all?

  Does one department manage all DirSync instances? Do you install multiple dirsync apps on a single server/load balanced cluster? Do you let the departments manage their own dirsync applications and another dept. audit it on a regular basis? Are you concerned with what is being synched to the cloud from on-prem AD?   I am trying get ahead of this potential nightmare in managing all dirsync for my institution.

  Thanks for your responses.   Brian Britt Vanderbilt University Security Operations | Identity Operations | Central Directory Services

Order By: Standard | Newest | Votes
patrickg posted this 31 May 2016

See below, if you need anything more detailed feel free to contact me off-list.

 

~Patrick

 

 

show

BrianB posted this 01 June 2016

Thanks Patrick,

 

Sometimes….

 

We have issues where a service is offered by a vendor that someone sees a need for. That service is purchased and we are then told to make it work. Upon investigation we find they need to Dirsync with their cloud

service and hopefully use SAML – In some cases there are cloud vendors who still will not implement SAML and rather invent their own way. I have some concerns over what is being sync’ed and what they are doing with the data at rest in the “data center”.  I

also still have concerns – even with O365 – with syncing my passwords.

 

Brian Britt

 

show

SamErde posted this 01 June 2016

It seems like using one monolithic, cloud-based identity provider/services is becoming more feasible than syncing to multiple services. Azure AD and Okta (probably others as well) both provide a single point of directory sync along with SSO for a large number of other cloud-based applications. Are you finding that these two services do not provide enough connectivity to other cloud-based applications, or are you not satisfied with their level of protection?
I've done some work with an organization that is using a limited subset of Office 365 functionality and have been able to significantly reduce the number of attributes that are synced so that there is almost no PII and no password hash. They are also using Ping Federate for SSO, which wasn't too difficult to set up once we found updated documentation.
Sam


show

BrianB posted this 01 June 2016

Sam,

 

Unfortunately, we have not moved into the Azure AD subscription just yet, only O365. So, we don’t have the Federation capabilities that comes with that subscription.

The dirsync, I am told is so the vendor can match a cloud based ID to an on-prem ID when Authenticating. We do want the ability to lifecycle ID’s in the different cloud vendors, so I can see the benefit.



 

SIDEBAR: Still I am finding that SAML adoption with some of these cloud vendors is slow and in some cases not even thought about. They want an MPLS or VPN connection

into the network to auth against the DS or they have their own Proprietary protocol that they use rather than SAML.



 

I can think of two or three different cloud services that we are using right now that have their own Dirsync installed on a server that has to be maintained.

Multiply that by X for each cloud vendor that wants to provide a service and the Dirsync(s) can become unwieldy.



 

Brian

 

 

show

darren posted this 01 June 2016

Brian-

Honestly, I think you have to get ahead of these kinds of scenarios by coming up with a standard way that your team will support for federating with partners. At customers

I’ve worked with, they mandate SAML and some kind of automated or semi-automated, standards-based provisioning (e.g. SCIM, JIT, bulk upload etc.) for their service providers. DirSync is kind of overkill for simple provisioning of SP accounts, if you ask me.

Only folks like MS with Office365 have a need for that level of synchronization. If an SP can’t support something less than DirSync, then they should be asked to get there as function of your business relationship. I realize that is sometimes tough to sell,

but you have to weigh the business risks of scattering your identity data all over the place with the benefits that vendor provides, and management needs to understand/accept that risk.



 

In terms of password sync, again, I think that is also a risk management exercise. I suspect there are worst vendors to sync AD password hashes to than Microsoft, but in the

end, you have to decide if the convenience outweighs the risks for your org.



 

Darren

 

show

patrickg posted this 01 June 2016

In the last four years, we’ve only had onetime where were are sending data to a third party (username and affiliation only). We’ve been trying to have someone from IT

included in the evaluation/purchasing of any new products and have been including SSO (either being ADFS, SAML, or SAML via InCommon) as a requirement. Anytime a vendor states that they want LDAP connectors, the answer is we no longer support LDAP connections.

The big part is getting departments/schools to involve IT from the start when looking at new software or SAS package, even if they know they want a particular package, prior to purchasing the product is when you have the most leverage on the vendor. Vendors

create products based upon what they can sell, if they can’t make sales because they lack SSO support… surprisingly they may start adding support for it.



 

Beyond the ability to control what attributes of a user’s object they are allowed to see, it removes the potential vulnerability of a third-party website getting hacked

and then credential farming users. All it takes it one time when credentials get harvested that can potentially cause data leakage and significant brand damage which can cause potential enrollment issues and donor reductions.

 

http://www.huffingtonpost.com/kyle-mccarthy/five-colleges-with-data-bb6474800.html

 

https://www.universitybusiness.com/article/hard-costs-data-breach

 

 

With O365 password syncing is not a hard requirement and you can adjust within the FIM interface what attributes are being allowed out, depending on what services are

being used, you may or may not need to sync all attributes.

 

 

~Patrick

 

 

show

barkills posted this 01 June 2016

Unfortunately, we have not moved into the Azure AD subscription just yet, only O365. So, we don’t have the Federation capabilities that comes with that subscription.

The dirsync, I am told is so the vendor can match a cloud based ID to an on-prem ID when Authenticating. We do want the ability to lifecycle ID’s in the different cloud vendors, so I can see the benefit.



 

[BA] The above paragraph doesn’t make sense to me. Office 365 gives you Azure AD. Azure AD is free. Every Microsoft Online application that is branded “office

365” requires an Azure AD logon token. The only partial exception is Yammer, where you can choose whether to leverage Azure AD or not. Having an Azure subscription has little to do with Azure AD.



https://blogs.technet.microsoft.com/ad/2016/02/26/azure-ad-mailbag-azure-subscriptions-and-azure-ad-2/ is a good resource to understand the relationship between an Azure subscription and Azure AD.


 

Put simply, federating authentication with Azure AD is not dependent on possession of an Azure subscription. It is also not dependent on Azure AD premium

(which is not free). There are Azure AD premium features  (and keep in mind that AADp is per user, NOT per tenant) that are distantly related to federation, but it is a stretch of imagination to equate AAD federation with anything you’d need to procure beyond

Office 365 licensing.


 

SIDEBAR: Still I am finding that SAML adoption with some of these cloud vendors is slow and in some cases not even thought about. They want an MPLS or VPN connection

into the network to auth against the DS or they have their own Proprietary protocol that they use rather than SAML.



 

[BA] OpenID + OAuth2 is becoming a more common combination than SAML—for good reason too.

 

I can think of two or three different cloud services that we are using right now that have their own Dirsync installed on a server that has to be maintained.

Multiply that by X for each cloud vendor that wants to provide a service and the Dirsync(s) can become unwieldy.



 

[BA] We have one other cloud “sync” process—to Google Apps for Education. We use the APIs Google provides for that. It’s probably also worth noting that we need multiple

“sync” processes for Microsoft, one for identities and one for licensing. I’ve also been considering a separate one for groups because Microsoft’s groups story is really disjoint currently. However, I don’t see this as significantly different than any other

service that needs accounts provisioned. We’ve had a provisioning framework in place for that kind of thing for 15-20 years, with many dozens of services using it. The only thing different about this is cloud and that’s not really that different.


 

Brian

 

 

show

Close