Authentication Contexts AD vs OD and FERPA

[rmleonard]

okay – here is a doozy – (this all applies to 10.4 – not 10.5 – still testing there)

In DOT EDU land – FERPA is raising its head to new heights and levels of annoyance…

I have give or take 700+ Macs under my control, and using the fantabulous Golden Triangle (though somedays, it could be the Cylinder of Destiny…)

Our AD implementation is having new restrictions put into place, such that an authenticated user cannot view group memberships to groups that they do not belong to.

So, when they turned off the Windows Pre-2000 group, macs started dropping log-ins…

I have Labs where only students in certain classes, and/groups are allowed to log in – groups that are now “privatized”

My main questions are:
What Context does a Mac/User use when connecting to AD – The machine or the user?
for example –
when I log in with a local admin account, and then run dscl to query a group as such:

dscl localhost -read /Active\ Directory/ourdomain/Users/username memberOf

if the machine is in the “privileged” group – i get a listing of what groups a particular user is in, when the machine is placed in a normal OU and granted no special permissions – I get nothing (which by the windows AD admins descriptions is what is supposed to happen)

but then – (the catch)

a Mac Machine that is not in the priviledged group, will not allow AD defined users to log in, only OD or local users.

so the questions are, how do we make the Macs more “Windows” like for authentication?
is it possible to make the authentication run in “User” context, and not “Machine”?
(I got the “Lecture” about how dumb Macs were to allow things run as a system-priviledge account, ie: Machine, instead of user context… )
– I smiled and said, we have no viri, nor malware issues –
that aside…

Just how are the AD Bindings held or created?

I’m also getting reports of folks not being able to get to fileshares, and I am starting to wonder if this is also an issue..
a share defined on an XSERVE/XRAID with ACLs allowing/denying based on AD groups (actually, an OD group made up of several AD groups, some of which are the new private category)

What kinds of “Gotchas” should I be on the lookout for?

again, it boils down to the interpretation of FERPA – which in this case, in simple terms – if you aren’t in a group, you can’t enumerate any memberships – the machines are not in auto-populated “private” groups only users. and therefore – unless the machine is granted special privs, it won’t let folks log-in…

they don’t like the idea of adding all macs into the priv’d group.. kinda defeats the purpose…

Does ADmitMAC do things differently?
are there other AD plugins or AD extensions that would solve the problem?

Rich

[Author]

Posts