LDAP AD SECURITY GROUP - SMART GROUP WORK AROUND

[Malcolm]

With my school's active directory we use a user creator system, which imports data that has been exported out of our student management system, and creates the users AD account, Password, security groups for their class enrolment and other AD user fields.

The intent was to use the security group to create smart mobile device groups to allocate apps based on their their grade security group from AD. To remove the need to manually group our students in JAMF.

As there doesn't appear to be an option to create a smart group from AD security groups or OU's, I was able to leverage the AD LDAP mapping field Department which was also populated with the students grade, with our AD importing program.

The catch was we were using the department field of AD for the details, however JAMF would not let us populate the same department reference data from AD for the department LDAP mapping field. I believe the departments field can't be used because this is due to the departments section of JAMF.

Instead we put the department field into the Room field, and then created smart groups to group the students based on the data allocated to the Room option which was collected from our users AD department mapping.

For those capable of doing the same with their users AD information, I hope this helps.

[bentoms]

The department field can be used, you just need to create them on the JSS 1st.

http://macmule.com/2014/05/04/submit-user-information-from-ad-into-the-jss-at-login-v2/

[calum_rmit]

same with building etc etc if you have an attribute in AD then you should be able to map it to whatever you like in the JSS Room/Dept/building etc etc, then you can smart group off of this.
This is what i have been doing for a long time :)

[fabian_ulmrich]

It just works by creating the Departments in JSS. Since the departments are created, the Informations will be pulled from AD correctly. Before I used to pull the informations via a little script pulling AD informations via `dscl` command, but in some cases I ran into problems because the client computer could not connect to my AD from external. Because of the method I used before, I needed to get rid of all the informations in "User & Location" to pull the new Informations via JSS LDAP connector. Here I use another script to manage this...

#!/bin/bash
# Read AD attributes

# Variables
LOGFILE="/private/var/log/readADattributes.log"
DATE=`date "+%d.%m.%Y - %H:%M:%S"`
LOGIN=`ls -l /dev/console | awk '{print $3}'`


# Creating Logfile
/usr/bin/touch "${LOGFILE}"
echo "${DATE}___Logfile created" >> "${LOGFILE}"


# Check if logged in User is an administrative account - if so, exit script
if [ "${LOGIN}" == "ladmin" ] || [ "${LOGIN}" == "adobeinstall" ] || [ "${LOGIN}" == "root" ] || [ "${LOGIN}" == "wtmp" ]; then
    echo "${DATE}___Wrong user "${LOGIN}", exit here" >> "${LOGFILE}"
    exit 1
else
    # Read AD attributes into variables.
    # Run Recon and insert dscl values in JSS User & Location fields.
    echo "${DATE}___Removing all user and location information" >> "${LOGFILE}"
    /usr/sbin/jamf recon -endUsername "-" -realname "-" -email "-" -position "-" -department "-" -phone "-" -room "-"
    echo "${DATE}___Writing AD attributes into variables" >> "${LOGFILE}"
    /usr/sbin/jamf recon -endUsername "$LOGIN"
fi

exit 0

Thanks again to @bentoms...I just was able to manage this because of your cool Blog.

[tkimpton]

The department and building information in the JSS is a very bad design flaw that has existed for a number of years.

You have to add all the departments manually in to the jss and when a ldap look up happens if the AD account isn't EXACTLY the same without abbreviations the information doesn't poppulate... Poor

For many years u used a script to send the department and building information. Due to my new place using likewise on older builds ( which doesn't show that via a script pulling from dscl information) I'm forced to use this dreadful jss built in mechanism.