SSO User / ldap group

[anniwayy]

Hi , we are trying to setup SSO and ran into an issue where users in an ldap group are not recognized and get access denied. Only ldap users directly added to JSS are recognized and signed in.

Any idea how this can be solved ?

thanks

[Taylor_Armstron]

Bump. Running into same issue, just posted a thread about it.

Any progress on your end, @anniwayy ?

[anniwayy]

Unfortunately not, but we have a working case. When we find the solution i will posted here.

:-)

[bugsin]

you need to make sure you are adding ldap groups to Jamf as well as on the identity provider access side. keep in mind they are case sensitive

[gachowski]

I think this is a known issue, you should reach out to Jamf..

C

[stuart_harrop]

I've opened a case for this as well with our Jamf Buddy

[Taylor_Armstron]

My ticket was closed out basically explaining that SSO logins will not do a lookup. Sucks, but explains what I'm seeing. Means managing all access is going to be a manual task on my plate, instead of just being able to set up AD groups and let each department manage their own.

[jdk6]

I have a need for this exact use case, and had also opened a ticket.

The answer was the same, so I have submitted a feature request to get it changed... please vote on it!
https://www.jamf.com/jamf-nation/feature-requests/8404/saml-authentication-+-ldap-authorization

[Ctinker]

In our environment I added the LDAP groups directly to Jamf as groups and when a user logs in via SSO (As in redirected to our IDP and then the IDP returns the response back to the SP-Jamf) they are logged in using their active directory username. The groups that this username is a part of are added to Jamf already and permissions are assigned to the groups themselves. Not the users one by one. I'm sorry I had to black out so much but basically these are all LDAP groups(as you see on the right) and after the user utilizes SSO, they are assigned permissions based on their membership to these groups. (Which is defined in active directory, not jamf)

[Taylor_Armstron]

Thanks @Ctinker

FWIW, that is exactly what we tried to do, and failed. When I opened a support ticket, I was told that SSO would not perform group lookups, and ticket was closed.

Now... the one additional wrinkle that we have is that we're using SSO via smart cards. Maybe that's part of the issue we had. Username/pass logins worked fine, but not when we used our smart cards (CAC/PIV).

[stephenb]

@Ctinker If I read your message right, you're using SSO (what idP?), backed with LDAP groups. This isn't working for me; what did you do to get it working?

[spyguitar]

I was able to get this working yesterday, following the documentation here: https://www.jamf.com/jamf-nation/articles/436/configuring-single-sign-on-with-active-directory-federation-services

Here's the setup:

• SSO is not yet configured or enabled
• We have our AD set up as an LDAP server in Jamf.
• We have an AD security group called "JSS Admins"; members of that group should get admin rights in Jamf. -- Note - AD distribution groups don't work for this purpose
• I added the JSS Admins group to Jamf as an LDAP group, and confirmed that group mappings work correctly on the LDAP side (in Jamf's LDAP server settings, the User Group Membership Mapping test succeeds)

At this point, users who are in the JSS Admins group in AD can log in with their AD credentials. They don't need to be added explicitly as a Jamf Pro user.

• Now, configure and enable SSO, using the recommended settings from the documentation above

At this point:

• AD users who are also Jamf Pro users will be able to log in via SSO, using their AD credentials
• AD users in the JSS Admins group who are not Jamf Pro users will get "Access Denied"

To get SSO group mapping working:

• in your Jamf SSO settings, the setting "Identity Provider Group Attribute Name" should be set to "http://schemas.xmlsoap.org/claims/Group"

To find the proper value for the above:

• open AD FS Management on your AD server
• find your JSS in Relying Party Trusts; select it, then click Edit Claim Issuance Policy
• you should only have one rule - select it, then click Edit Rule
• click View Rule Language
• in the rule language, you'll see a "types =" clause followed by a "query =" clause. The items in the "types =" clause are what will be passed back to the Jamf server, and they correspond with the items in the "query =" clause.

Once I had this in place, I could log into the JSS as a user who is not a Jamf user but who is an AD user in the JSS Admins group.

[cainehorr]

... comment removed ...

[rstasel]

@spyguitar

I believe this only works because you're using AD for your SSO provider, so it's passing group information with the SSO login (so Jamf is seeing that group name, looking at the group list it has assigned, then looking up members of that group to match the user logging in). If you use a separate SSO provider (say, Shibboleth) you may not have that group info present. Jamf doesn't appear to be smart enough to grab that user, check users and groups, see that user is missing, then query ldap/AD for the user's group membership, and allow login based on that...

[homepup]

Ran into this same issue using Shibboleth as our SSO and the final fix to get it to process the ldap groups properly was to set the Group membership to "urn:mace:dir:attribute-def:memberGroup" (essentially the FQDN)