If they don't need access to it generally you could create a software restriction that disallows students from opening Keychain Access at all. Applications can still write password entries to it but users can't look at the entries themselves.

@psliequ cool, oversaw this option. It works quite. But here comes my layciness: There is no option to disallow a specific app. In 9.96 i only can Allow apps, allow folders or disallow folders. I can you build a policy containing all allowed apps and have to modify it maybe if a new app comes in (will be a lot with our BYOD-Macs) or I disallow the Utilities folder. I tested the last solution and figured out: If you copy the keychain app (what is possible even if the launch of apps from Utilities folder is prohibited) to the applications folder you can open the copy.

Instead of a Configuration Profile, look at the section in Jamf Pro for 'Restricted Software.' You have finer grained control there over what specific processes are allowed to run, and moving the app to a different location in the filesystem will continue to block the process.

Yes...sorry...but...than a administrator also cant access the keychain access. I would love to have a mixture of both. A restricted software policy that I can scope to user level. Feature request?

Not sure if this will help or not. But we use a machine certificate for authentication to our WiFi. We embedded that into a profile. So that way you don't need a password just the right profile/cert combo. Just a thought.

We had problems with that but they got solved when we went 802.1X. That solved that problem but opened quite a few other cans of snakes.

We've tried this approach, but with Monterey, we can't automatically renew the AD machine cert, and any attempt to replace it or its associated profile kicks the machine offline and it won't reconnect. How do you manage this?  We're using Radius, Machine credentials, AD certs.