Home › Forums › OS X Server and Client Discussion › Active Directory › Mac Clients, RFC 2307, Active directory, FERPA, Security and more… OUCHIE
- This topic has 4 replies, 2 voices, and was last updated 17 years, 4 months ago by
rmleonard.
-
AuthorPosts
-
November 5, 2007 at 7:39 pm #370436
rmleonard
Participantthings are getting worse around here…
in efforts to make the AD servers more “RFC 2307” unixie compliant, certain groups are becoming “privatized”, meaning that if you aren’t in the group you can’t query it.
(this makes the FERPA people happier)In my Golden Triangle environ… it breaks things….
a Client bound to both AD and OD, this machine (or suite of machines in a lab setting) has access limited to log in…
For example, I have a Music Lab, and I would like to limit access to all students in Music_Classes and faculty in Music_Faculty.both of those groups exist in AD, on my OD server I create a group called Music_Lab_Access and give it two members, the groups from AD.
HOWEVER – the _MACHINE_ is not in either group and difficulties ensue.
So Far, the only way to patch this is to put the Macs into a “Pre-Windows 2000” group or somesuch on the AD side.
this gives the machines access to read what the user can’t and then authenticate them.What kinds of privacy issues are dealt with out there in your realms, and how do you overcome them?
Rich
November 30, 2007 at 2:57 pm #370663smb445
Participantrmleonard,
The main problem is getting access to the memberOf attribute on user and group accounts. By removing Everyone from the pre-Win2k group, machines no longer have access to read that data – you could narrow the scope of what you need by creating a new group (or using the Pre-2K group) with the computer accounts and granting those members access to the memberOf attribute itself. That way you can determine group memberships (which is what you want) and still gain the other security benefits.
-smb
November 30, 2007 at 3:11 pm #370664rmleonard
ParticipantThe problem with granting the machines access via a “Pre Win2K” to credential level is that anyone with access to terminal could then use DSCL to browse the memberOf attribute – So we are in a catch-22 position – on the one hand the desire to be “secure” and then the inability to make it so due to the limitations of “how things work”.
A lab is where the security needs to be the tightest, and yet, to make it work – we need to make the labs insecure –
Is there a way to encrypt all of this? So that the “machine” can understand what goes where, but that it is human “unreadable”?
Rich
November 30, 2007 at 6:18 pm #370667smb445
ParticipantNo – the AD plug-in doesn’t support SSL connections…you might be able to monkey around with ssh tunneling, but you have to do a lot of heavy lifting on both sides of the fence and wandering fall afield into the unsupported territories.
Out of curiosity – if a user could determine someone’s group memberships, what does that buy them (from a security breach perspective) ?
November 30, 2007 at 6:28 pm #370668rmleonard
Participant[QUOTE][u]Quote by: smb445[/u][p]No – the AD plug-in doesn’t support SSL connections…you might be able to monkey around with ssh tunneling, but you have to do a lot of heavy lifting on both sides of the fence and wandering fall afield into the unsupported territories.
Out of curiosity – if a user could determine someone’s group memberships, what does that buy them (from a security breach perspective) ? [/p][/QUOTE]
Our gloriously tinfoil hatted leader – the campus ISO – (usually a nice guy… but in this case…)
believes that if one could glean, for instance, a class roster, then one could begin stalking a particular subset of said class roster… these smaller units are usually termed “Students”..
I have found over time, that these are interchangeable, transient, and very ephemeral particles. around here they only seem to last 9-10 weeks at most, and then rotate.
That being said, “Policy” is still being decided.
the ability to use auto-populated group lists means that I can use AD to define a group in OD of, say, Basketweaving101 users, and then lock lab use to only students in basketweaving classes, set up once and each and every quarter – the “system” auto resets itself to a new batch of students…
This process has been running on autopilot for several years, now with this new security push – I’m getting a bit stressed out.
if the OD server had permissions to view the group, and the client simply got a kerb ticket from the OD server to pass back to AD, then life would be good. Students have no CLI access to the server.
Overall the Golden Triangle has been rock solid for quite some time…
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed