Apple SSO Extension + Jamf

Contributor III

Does anyone use Enterprise Connect or the Apple SSO Extension in an environment with multiple realms? and how do you deploy this out or configure it?

For example, we have our user ids in different dc's or realms (excuse my lack of AD knowledge), so if my user id is XX1234 and I belong to US3 realm, (we currently use NoMAD) so my realm would be that will let me use my user id of XX1234.
if I tried just it won't work as the nomad or SSO tool will think the account is, I tried a few variations of it too: (thinks the username is and so on.

I opened a case with enterprise support, but so far their engineers dont think its possible to identify multiple realms. inside the config profile you can technically create additional REALM entries but it seems to pick a random one and does not really function how I'd hope it would.

the other solution is just making multiple config profiles available via self service to our users to install as I dont see a way in Jamf to scope to a Domain or DC natively.


New Contributor II

have you defined multiple hosts preceded with a period. For example in your case it should or

Contributor III


Did you resolve? We are similar we have users in the top-level domain and sub-domains, e.g

and so on

The SSO realm is set in Jamf profile to COMPANY.NET and we have added in multiple hosts of .ASIAPAC.COMPANY.NET etc but if a user in a subdomain of logs in the SSO dropdown shows

So a strange double @

Contributor III

I managed to resolve this by having an EA that collects the user's domain or subdomain. Then smart groups for each domain via the EA data collect and individual Profiles for each domain scoped to the relevant smart group.

So 4 smart groups, 4 profiles.

New Contributor III

We've using Enterprise Connect and the Kerberos SSO extension for Catalina users in a multi domain environment. A profile for each domain so it's locked in and smart groups that pickup on the users country or domain from the UPN value then repeat for Catalina users as it's a separate profile.

Contributor III

@MatG @Noonan Yes, this was resolved by using out LDAP extension attributes to pull in an identifier for their realms. wildcarding .corp.domain does not work in our environment as looksups dont appear to traverse that way for this. Same issue with NoMAD.

I have individual Config Profiles for each domain, that scope to a smart group that uses the LDAP extension as its source and this so far has worked solid.