I tried doing this with Casper 9.63 and OSX 10.9. I experienced the same issue and was told by JAMF it was a bug on Apple's part. It's unfortunate to see this hasn't been fixed in 10.10. I ended up writing a script that runs with the login trigger that checks to see if the user is a member of one of my denied groups and kills the loginwindow process if so. It's rather brute force, but it works. I can get it to you if you want.

Okay - I'll write a Script then which will do that using the last two commands:
https://jamfnation.jamfsoftware.com/discussion.html?id=4591#responseChild22732

Good to know, that I'm not doing it wrong ;)

Hmmm....That post looks familiar. I feel like I tried that too. Can't recall if it didn't work, or if I just decided to go another route. For what it's worth, here's my method:

• Ongoing policy that runs at login
• Set target to computers on which you wish to restrict login
• Run the following script

#!/bin/bash

#Script to prevent login of users in specific AD groups
#As of OS X 10.9 MCX- and profile-based methods for this do not seem to be working
#Code borrowed from https://jamfnation.jamfsoftware.com/discussion.html?id=4591

user=$3     #Use existing Casper variable for user
groups=( DOMAIN\\AD_GROUP_1 DOMAIN\\AD_GROUP_2 )

for group in ${groups[@]}
do
    if [ "$(dsmemberutil checkmembership -U $user -G $group)" = "user is a member of the group" ]
    then 
        echo "$user is a member of $group.  Killing login session..."
        /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType fs -title "Login Not Allowed" -icon /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertCautionIcon.icns -description "Use of individual student accounts is not allowed.  This computer will return to the login window in 10 seconds." &
        sleep 10
        killall jamfHelper
        kill `ps -ef | fgrep loginwindow | grep -v grep | awk '{print $2}'`
    fi
done

Note that you could also remove the logic for specific AD groups from the script and instead use the Limitations portion of the policy scope to instead determine what groups are denied. This is probably the cleaner way to do it, but I didn't think of this until after the fact.

Good luck!
Eric

Haven't updated to Casper 9.7 yet, but noticed this in the bug fixes and enhancements. ‚
D-008199 Fixed an issue that prevented a user group from being added to a Login Window OS X configuration profile.

However, this is still listed under Known Issues:
‚‚
[D-005532] OS X configuration profiles with a Login Window payload that is configured to deny users and groups the ability to log in fail to do so.

Anyone upgraded to 9.7 yet and tried to see if there's any change in the configuration profile behavior?

I'm considering using Configuration Profiles to restrict access to specific AD groups.

Does anyone know if the bug(s) listed above have been resolved?

As they are still listed within the latest Release Notes I guess they arent fixed yet. :-(

That would make these bugs almost 2 years old. Wow.

Actually it's longer then that, as it even didnt work with 10.9 ;-)

Is this still a bug? Because yeah, it doesn't seem to be working with 10.11.6 and Casper 9.96.

I couldn't get this to work the way I needed it to via Config Profile as well. So, I took @etippett 's script and expanded on it a bit.

In our school environment, unfortunately not all our students logout of the computers they use. Rather than force subsequent students to power down the machine, we enable Fast User Switching to allow other students to continue to use the same machine. The addition of a for-do loop in the script allows us to identify which loginwindow process corresponds to the logging-in user and kill only that process.

Additionally, even though the loginwindow process gets killed, in my testing the user account still gets created, or at least partially. To get around this, I added a dscl command to remove the logging-in user's account from the local database and an rm to remove their home folder from the machine. I like logging, so I added a function and a log file to record when this runs on local machines.

Haven't deployed this yet, but in my tests with this applied to a policy, triggered at login, scoped to a test machine, this worked exactly as expected and only kills the logging-in user's loginwindow process when multiple users are logged in on the same machine.

#!/bin/bash

#Script to prevent login of users in specific AD groups
#As of OS X 10.9 MCX- and profile-based methods for this do not seem to be working
#Code borrowed from https://jamfnation.jamfsoftware.com/discussion.html?id=4591

USER=`/bin/ls -l /dev/console | /usr/bin/awk '{print $3}'`
LOG="/path/to/RestrictedLogins.log"
JAMFHELPER="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
windowtype="fs"
heading="Restricted Login"
icon="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertStopIcon.icns"
description="Student logins on this computer are restricted. Please use a different computer.

This computer will return to the login window in 10 seconds."

# function to write to log file
writelog () {
    /bin/echo "${1}"
    /bin/echo $(date) "${1}" >> $LOG
}

writelog "${USER} is a student. Killing login session ..."

# for-do statement to get all loginwindow processes and determine which one is for the logging-in user, so it can be killed
for LOGWINPID in $(/usr/bin/pgrep loginwindow) ; do
    P_OWNER=`/bin/ps -eo user,pid | /usr/bin/grep ${LOGWINPID} | /usr/bin/awk '{print $1}'`

    # When the process owner with the given loginwindow process ID matches 
    # the logged in user, presents jamfHelper message and kills that loginwindow process    
    if [ "$P_OWNER" = "$USER" ]; then

        "$JAMFHELPER" -windowType "$windowtype" -heading "$heading" -icon "$icon" -description "$description" & sleep 10

        killall jamfHelper

        kill -3 ${LOGWINPID}

        if [ $? = 0 ]; then
            writelog "${USER}'s login session successfully killed!"

            if [ -d "/Users/${USER}" ]; then
                writelog "${USER} home folder detected. Removing ..."

                /usr/bin/dscl localhost -delete /Local/Default/Users/${USER}

                /bin/rm -rf /Users/${USER}

                if [ ! -d "/Users/${USER}" ]; then
                    writelog "${USER}'s home folder successfully removed!"
                else
                    writelog "${USER}'s home folder removal failed."
                fi
            fi

        else
            writelog "${USER}'s login session was not killed."
        fi
    fi
done

exit

It's now 10.20.1. Just bump up this thread. Jamf, how is this making your product acceptable as the enterprise-ready solution with such critical and simple function still broken for 5 years and counting....