Smart Group members based on AD LDAP look up using Extension Attribute

[Oops_wasn_t_me]

Hello,

I'm working with a school and trying to set up Smart Groups based on AD groups to report on iOS devices owned by specific year group members (e.g. mobile devices being owned by year 8 users). At the end of every academic year, the member contents of the respective AD year groupings are updated to reflect students moving up a year (or not as the case may be). The idea is build a smart group (rather then static group) to be able to report, scope configurations or apply policies to specific year groups rather then specific individuals or static groups (of individuals).

But, there is a problem. When tested with specific user, EA settings appear to work correctly. i.e. for each user tested the correct year grouping is returned. However, when put into a Smart Group criteria (criteria -> Mobile Device Group), no results returned.

The steps used to create the Smart Group:
1. Create the Mobile Extension Attribute, with the Display Name of LDAP Group, input type set to LDAP Attribute Mapping and the LDAP Attribute set to memberOf.
2. Create the Smart Mobile Device with the criteria of LDAP Group is “distinguishedName of the” (e.g. CN=year 8,CN=users,DC=your,DC=domain,DC=com)

Can anyone spot something I am doing wrong ? Perhaps I am making incorrect assumptions ? I understand this is a user case scenario and is specific to the AD set up (... I am wondering if the '0' result is due to an issue of the same users being present in multiple groups). Has anyone using this approach manage to get it to work ? If not, is there a better approach to achieve my goals.

Appreciate your insight.
Have a great day.
Thank you.

[nelsonpark]

at a guess (as i have tried a similar thing)
i would say that the iOS devices are not actually joined to LDAP and therefor do not have the appropriate MemberOf AD attributes existing for it to retrieve at the device level.
Those AD objects do exist for all of your AD 'USER' accounts, however there is currently no LDAP Attribute Mapping that i could find within the User context of the Extension Attributes.

in theory its possible, but i couldnt work it out either. hopefully its something that JSS hasnt yet added ;)

My scenario is being able to have a smart group for all the staff members at our school and in this case, see if they have yet to actually log into itunes on the ipads, or havent turned on the ipad in the last say 30 days (device has not checked in)
Conor

[davidacland]

I would check what the EA is returning in the device inventory. If it's empty, that will tell you where the problem is.

[Oops_wasn_t_me]

Good Morning,

Thank you Conor and David for your reply. You've hit the nail on the head and I believe you have answered my question - sometimes it's had to see the wood for the trees. It would appear my approach will not work because of how LDAP (AD) works and how Casper is querying the request. For this functionality to work, there would have to be a change in approach or philosophy of how Casper treats LDAP as Casper (like most MDMs) does not cache LDAP records.

With the current workflow, the only way I could see how this approach might work is to 'attach a tag' to the mobile device at enrolment time and then search Caspers (internal DB) looking for the tag. Uggghhh.... it's appears to be so straight forward... but it isn't (the devil is in the details).

Thanks again for the insight !
Have a great day.

[russeller]

I haven't done this myself yet, but heard about a method that some institutions are using to tag iPads. At enrollment a config profile installs a web clip that points to an internal website. This website is created to have simple fields (drop downs) where the end user, who is enrolling the iPad, chooses options like what grade they are in. The internal site will send JSS API calls back that set attributes on the iOS devices. Hopefully a friendly Casper admin has already been down this road and can share.

Hope you find a workable solution

[plawrence]

@Oops.wasn't.me

Another way to solve this problem is to put the students Current Year or Cohort into a field in Active Directory that can be mapped to a field in Casper. I've also found out recently that you can create Mobile Device Extension Attributes to pull any field from AD into an Extension Attribute.

See below for an image (with personal information removed) of how our User and Location area looks. We have Position showing the Current Year and a new Extension Attribute showing the Cohort (or graduating year). Both of these can be used as criteria in Mobile Device Smart Groups

[cdenesha]

In addition to doing what @plawrence is doing, I also populate an EA with the OU that the user is a member of, as we happen to organize our grade level students into the same container.

My EA is called 'LDAP Parent OU', is an 'LDAP Attribute Mapping', and populates with distinguishedName. An example return would be CN=Student Name,OU=10th Grade,OU=STUDENTS,OU=USERS,OU=SCHOOLNAME,DC=your,DC=domain,DC=com. I then create Smart Groups with a criteria of 'LDAP Parent OU' LIKE 'OU=10th Grade'.

By moving the student from one OU to another when their grade changes, it automatically updates the SGs.

chris

[Oops_wasn_t_me]

Good Morning,

Great information and helpful suggestions ! Alas, any changes to the AD structure can not be facilitated. Here (Queensland, Australia), the State Schools are members of a AD forest managed by Department of Education. At the end of the academic year, the Dept updates the school/class membership and the changes are propagated throughout the whole state. I believe school level admins are unable to edit their local AD.

As Casper is implemented on a school-by-school scenario, the easiest option is to work within the functionality which is available locally; ssrussell suggestion may address the problem. I will also look further into the AD structure and see if there is any distinguishing year info which can be extracted (Thank you, plawrence and cdenesha.) I will undertake some experimenting and see how things develop.

I appreciate all the suggestions ! Lots of great ideas to consider.
Have a great day.

[mmcallister]

One way I found to do this:

Create a configuration profile to install a (small) font to the devices.
Scope the profile to members of the targeted AD Group.
Build a smart group based on presence of the profile.

Good luck!

[cdenesha]

This is an update with how we do things in my new district.

However first a comment on why the method @Oops.wasn't.me first used might not have worked: I tried to pull the LDAP Attribute memberOf earlier this year but it only returned one of the groups the user was a member of, and it wasn't consistent in which one was pulled.

In my new district we are currently doing it the same way that @mmcallister mentioned, a profile that is scoped with a Limitation of an AD group. Membership in the group is controlled by a sync between our SIS and AD, so AD is always up to date with what grade they are in. When Inventory Update reports that the profile has been installed, they'll be placed in a Smart Group. This SG can now be used for scoping instead of to All with Limitations.

Problem 1) It still depends on an initial LDAP Limitation.

Problem 2) I learned in the iOS 9.2 debacle that Update Inventory doesn't always return all information - it can be a partial update. However the JSS already set the profile count to zero in anticipation of the proper count. All of a sudden the JSS thought the iPads did not have any configuration profiles and they fell out of scope of the initial SG and all the rest that were based on it - including Managed Apps. I consider this a bug and wrote up this FR.

Problem 3) It seems that anything that checks AD Limitations puts more load on AD from repeated requests. If you're also scoping VPP with Limitations.. you are generating a LOT of AD and VPP traffic and using lots of resources. It can slow you down if your JSS is Hosted and your LDAP is local. Put your logs into debug mode and you'll see it! Also this FR.

So I'm going to restructure to do it the way @plawrence suggests up above. The same AD to SIS sync will keep their year of graduation up to date but in an AD attribute. This can be placed in an Extension Attribute which populates an SG, and now I can create all scopes based on this one SG. In addition, I don't want to have to keep re-scoping every middle school app with the current YoG, so I created one SG per grade level, i.e.:

'_Grade 08 - update criteria annually' with criteria 'Mobile Device Group' member of 'Class of 2020'.

The apps and profiles can be scoped to a grade level if you wish, and all you have to do is every August remember to update one SG per grade level.

Sorry for the longish post and I hope it makes sense - just trying to fine tune what we spoke about above.

chris

[robert_petitto]

@cdenesha Do you know if there's a way to include a string constant instead of an LDAP attribute in the LDAP Server --> User Mappings settings? (eg. I want Building to map to a constant like "Middle School" rather than the physicalDeliveryOfficeName LDAP attribute).

[cdenesha]

@robert.petitto No I don't think this is possible - it is an LDAP configuration so needs the LDAP attribute.