Main Nav

It is my understanding though that the standard attributes (cn and the like) cannot be marked confidential and so are visible to all authenticated users. You could try to use only custom attributes but then most AD-centric products would fail to work because they expect the standard attributes. Managing the AD itself would also become problematic because Microsoft's tools expect you to use the standard attributes. It appears to me that AD remains incapable of properly supporting FERPA requirements and confidentiality requests. I'd love to be proven wrong about this because we do have to support AD for Office365 and several AD-centric products and I am hesitant to support putting more of our enterprise identity data into AD because of this. Regards, Brendan Bellina USC

Comments

Currently we have custom programming sync our OpenLDAP and AD environments. This allows for security groups to be populated in AD that are then scripted to alter the ACL's on the accounts within AD. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
Message from michele.mueller.1@bc.edu

I would also be interested in knowing the solution to this.  We are getting the same request to populate course groups in AD, but we are concerned with FERPA and the memberof attribute

Michele Mueller
 


Chuck Phillips wrote:
Interesting topic,   We are exploring creating goups for class lists.  However, the memberof attribute in each persons AD entry exposes group membership.     Putting read rights on the memberof attribute will,  we are pretty sure, break more things than we are willing to sacrifice.   Exposing the memberof attribute is borderline FERPA violation since, in theory, an AD knowledgable student could stalk another student by seeing which classes they are enrolled in.    How are others dealing with class groups and the memberof attribute relating to FERPA? Chuck Phillips chuckp@unm.edu ________________________________________ From: Identity Management Constituent Group Discussion list [IDM@LISTSERV.EDUCAUSE.EDU] on behalf of Belleville-Rioux, Vincent [rioux.vincent@UQAM.CA] Sent: Tuesday, March 26, 2013 7:56 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? John, your setup is interesting. Out of curiosity, are you using AD as the topmost source of authentication or are you also using an identity manager to synchronize directories? Regards, Vincent -----Message d'origine----- De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de John Goodman Envoyé : 26 mars 2013 09:42 À : IDM@LISTSERV.EDUCAUSE.EDU Objet : Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? Here at UW-Milwaukee we recently implemented Ferpa protections within our Active Directory environment. Like Vincent mentioned below, we modified the ACL's on protected accounts to prohibit Authenticated Users. Service owners requiring access to these protected accounts are required to fill out an "access to services" form that is submitted to our Registrar's office for approval. Once approved, the service account is added to a security group that is permitted to access the protected accounts. I would say that the process we have in place has worked quite well, but not without some initial issues. Even with proper communication the behavior of these protected accounts still confused some distributed administrators which created some un-necessary troubleshooting. Some initial "gotchyas" were... - OSX requires read access to the General and Public attribute sets to allow for a user to authenticate. - Distributed administrators are unable to add these users to security groups without being added to the "ferpa administrator" group themselves If anyone is interested in a more detailed explanation of our current configuration, please feel free to contact me. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
Hello,

We've got a combined LDAP (Fedora variant) and Active Directory environment with passwords synced to both systems, and are looking at simplifying our identity/directory infrastructure by consolidating to just Active Directory.

Has anyone brought up or migrated to such an environment? If so, what advice or gotchas do you have to share, if any?

Perhaps a vague/loaded question; happy to clarify if needed.

Thank you!
Mike

Mike Osterman
IT Security Officer/
Deputy Director, Enterprise Technology
Whitman College
(509) 527-5419

Hi Mike,

 

At my previous employer, where I worked for the past 10 years, we did exactly this.  It was a rather small (some would say minuscule) setup with around 400 active students and less than 50 active teachers and professors using around 300 workstations and half a hundred servers or so.  However, it suited us very well as the flexibility, ease of use and large community of AD-based companies meant our growth (over 6x in 10 years) was not a problem and we could keep the IT needs well in check (less than 2x the budget in that same time period).

 

We also built a PHP-driven management interface for the provisioning and management of all accounts and groups.  By using AD only, we were able to offer single sign-on and simple unified interfaces for account management pretty easily.  From the admission to the alumni, everything was managed though web interfaces and security was provided by binding with the active user in almost all cases.  All services were managed by security groups (FTP access, Intranet access, VPN access, etc.) with a group for each user role giving rights to the related security groups in a nice top-down tree.

 

One thing that might be an issue however is CAL licensing.  Also, since we were a mostly Microsoft shop, it was quite easy to implement such a scenario (Exchange, MSSQL, etc.)

 

We did also have Linux boxes integrated within the domain with AD authentication without any problem.

 

One of the things you should be aware of is that once you have an AD-only directory system, any issue you might have with that directory makes your entire organisation at risk.  We had very few problems with the software, but hardware issues did arise.  In time, we made improvements in our processes and we were able to prepare for most possible troubles by having DCs as read-only replicas on hot standby and by keeping a few parts on hand.

 

Oh and one other thing : should you decide to go that route, I’d be very interested in your deployment size as my new employer is a much more sizeable university and we’re currently investigating the best way to merge or synchronize our identity directories.

 

Vincent

 

De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de Mike Osterman
Envoyé : 22 mars 2013 19:34
À : IDM@LISTSERV.EDUCAUSE.EDU
Objet : [IDM] Anyone using Active Directory as sole (enterprise) directory server?

 

Hello,

 

We've got a combined LDAP (Fedora variant) and Active Directory environment with passwords synced to both systems, and are looking at simplifying our identity/directory infrastructure by consolidating to just Active Directory.

 

Has anyone brought up or migrated to such an environment? If so, what advice or gotchas do you have to share, if any?

 

Perhaps a vague/loaded question; happy to clarify if needed.

 

Thank you!

Mike

 

Mike Osterman

IT Security Officer/

Deputy Director, Enterprise Technology

Whitman College

(509) 527-5419

 

Message from atlunde@panix.com

We don't use Active Directory as our sole directory service, but we've been forced to make it more important to make Outlook/Exchange email work. One main pitfall is the privacy model: too much information goes to Authenticated Users by default. One gimmick you can use to make private information coexist with widely shared information is to define custom LDAP attributes and mark them as "confidential attributes" in the schema.
It is my understanding though that the standard attributes (cn and the like) cannot be marked confidential and so are visible to all authenticated users. You could try to use only custom attributes but then most AD-centric products would fail to work because they expect the standard attributes. Managing the AD itself would also become problematic because Microsoft's tools expect you to use the standard attributes. It appears to me that AD remains incapable of properly supporting FERPA requirements and confidentiality requests. I'd love to be proven wrong about this because we do have to support AD for Office365 and several AD-centric products and I am hesitant to support putting more of our enterprise identity data into AD because of this. Regards, Brendan Bellina USC
You are correct : only base schema attributes are restricted from being set as confidential. http://support.microsoft.com/kb/922836/en-us However there might be ways to be FERPA-compliant by reducing what Authenticated Users have access to and to grant read access only to service accounts used by administrators or other software. Your hesitation is pretty well founded but I wouldn't say AD is incapable of being adapted that way. It would be a very interesting use case to try and test in a lab environment. Vincent -----Message d'origine----- De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de Brendan Bellina Envoyé : 25 mars 2013 20:03 À : IDM@LISTSERV.EDUCAUSE.EDU Objet : Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? It is my understanding though that the standard attributes (cn and the like) cannot be marked confidential and so are visible to all authenticated users. You could try to use only custom attributes but then most AD-centric products would fail to work because they expect the standard attributes. Managing the AD itself would also become problematic because Microsoft's tools expect you to use the standard attributes. It appears to me that AD remains incapable of properly supporting FERPA requirements and confidentiality requests. I'd love to be proven wrong about this because we do have to support AD for Office365 and several AD-centric products and I am hesitant to support putting more of our enterprise identity data into AD because of this. Regards, Brendan Bellina USC
Here at UW-Milwaukee we recently implemented Ferpa protections within our Active Directory environment. Like Vincent mentioned below, we modified the ACL's on protected accounts to prohibit Authenticated Users. Service owners requiring access to these protected accounts are required to fill out an "access to services" form that is submitted to our Registrar's office for approval. Once approved, the service account is added to a security group that is permitted to access the protected accounts. I would say that the process we have in place has worked quite well, but not without some initial issues. Even with proper communication the behavior of these protected accounts still confused some distributed administrators which created some un-necessary troubleshooting. Some initial "gotchyas" were… - OSX requires read access to the General and Public attribute sets to allow for a user to authenticate. - Distributed administrators are unable to add these users to security groups without being added to the "ferpa administrator" group themselves If anyone is interested in a more detailed explanation of our current configuration, please feel free to contact me. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
John, your setup is interesting. Out of curiosity, are you using AD as the topmost source of authentication or are you also using an identity manager to synchronize directories? Regards, Vincent -----Message d'origine----- De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de John Goodman Envoyé : 26 mars 2013 09:42 À : IDM@LISTSERV.EDUCAUSE.EDU Objet : Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? Here at UW-Milwaukee we recently implemented Ferpa protections within our Active Directory environment. Like Vincent mentioned below, we modified the ACL's on protected accounts to prohibit Authenticated Users. Service owners requiring access to these protected accounts are required to fill out an "access to services" form that is submitted to our Registrar's office for approval. Once approved, the service account is added to a security group that is permitted to access the protected accounts. I would say that the process we have in place has worked quite well, but not without some initial issues. Even with proper communication the behavior of these protected accounts still confused some distributed administrators which created some un-necessary troubleshooting. Some initial "gotchyas" were... - OSX requires read access to the General and Public attribute sets to allow for a user to authenticate. - Distributed administrators are unable to add these users to security groups without being added to the "ferpa administrator" group themselves If anyone is interested in a more detailed explanation of our current configuration, please feel free to contact me. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
Currently we have custom programming sync our OpenLDAP and AD environments. This allows for security groups to be populated in AD that are then scripted to alter the ACL's on the accounts within AD. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
Interesting topic,   We are exploring creating goups for class lists.  However, the memberof attribute in each persons AD entry exposes group membership.     Putting read rights on the memberof attribute will,  we are pretty sure, break more things than we are willing to sacrifice.   Exposing the memberof attribute is borderline FERPA violation since, in theory, an AD knowledgable student could stalk another student by seeing which classes they are enrolled in.    How are others dealing with class groups and the memberof attribute relating to FERPA? Chuck Phillips chuckp@unm.edu ________________________________________ From: Identity Management Constituent Group Discussion list [IDM@LISTSERV.EDUCAUSE.EDU] on behalf of Belleville-Rioux, Vincent [rioux.vincent@UQAM.CA] Sent: Tuesday, March 26, 2013 7:56 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? John, your setup is interesting. Out of curiosity, are you using AD as the topmost source of authentication or are you also using an identity manager to synchronize directories? Regards, Vincent -----Message d'origine----- De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de John Goodman Envoyé : 26 mars 2013 09:42 À : IDM@LISTSERV.EDUCAUSE.EDU Objet : Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? Here at UW-Milwaukee we recently implemented Ferpa protections within our Active Directory environment. Like Vincent mentioned below, we modified the ACL's on protected accounts to prohibit Authenticated Users. Service owners requiring access to these protected accounts are required to fill out an "access to services" form that is submitted to our Registrar's office for approval. Once approved, the service account is added to a security group that is permitted to access the protected accounts. I would say that the process we have in place has worked quite well, but not without some initial issues. Even with proper communication the behavior of these protected accounts still confused some distributed administrators which created some un-necessary troubleshooting. Some initial "gotchyas" were... - OSX requires read access to the General and Public attribute sets to allow for a user to authenticate. - Distributed administrators are unable to add these users to security groups without being added to the "ferpa administrator" group themselves If anyone is interested in a more detailed explanation of our current configuration, please feel free to contact me. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
Message from michele.mueller.1@bc.edu

I would also be interested in knowing the solution to this.  We are getting the same request to populate course groups in AD, but we are concerned with FERPA and the memberof attribute

Michele Mueller
 


Chuck Phillips wrote:
Interesting topic,   We are exploring creating goups for class lists.  However, the memberof attribute in each persons AD entry exposes group membership.     Putting read rights on the memberof attribute will,  we are pretty sure, break more things than we are willing to sacrifice.   Exposing the memberof attribute is borderline FERPA violation since, in theory, an AD knowledgable student could stalk another student by seeing which classes they are enrolled in.    How are others dealing with class groups and the memberof attribute relating to FERPA? Chuck Phillips chuckp@unm.edu ________________________________________ From: Identity Management Constituent Group Discussion list [IDM@LISTSERV.EDUCAUSE.EDU] on behalf of Belleville-Rioux, Vincent [rioux.vincent@UQAM.CA] Sent: Tuesday, March 26, 2013 7:56 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? John, your setup is interesting. Out of curiosity, are you using AD as the topmost source of authentication or are you also using an identity manager to synchronize directories? Regards, Vincent -----Message d'origine----- De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de John Goodman Envoyé : 26 mars 2013 09:42 À : IDM@LISTSERV.EDUCAUSE.EDU Objet : Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server? Here at UW-Milwaukee we recently implemented Ferpa protections within our Active Directory environment. Like Vincent mentioned below, we modified the ACL's on protected accounts to prohibit Authenticated Users. Service owners requiring access to these protected accounts are required to fill out an "access to services" form that is submitted to our Registrar's office for approval. Once approved, the service account is added to a security group that is permitted to access the protected accounts. I would say that the process we have in place has worked quite well, but not without some initial issues. Even with proper communication the behavior of these protected accounts still confused some distributed administrators which created some un-necessary troubleshooting. Some initial "gotchyas" were... - OSX requires read access to the General and Public attribute sets to allow for a user to authenticate. - Distributed administrators are unable to add these users to security groups without being added to the "ferpa administrator" group themselves If anyone is interested in a more detailed explanation of our current configuration, please feel free to contact me. John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577
Message from rwilper@stanford.edu

I do not know if Brian Arkills is on this list, he usually gives the FERPA spiel over on the Windows-Hied (windows-hied@lists.stanford.edu) or ActiveDir (activedir@mail.activedir.org) lists. This topic comes up on Windows-hied fairly frequently.

 

The FERPA answers usually fall into 2 categories

1)      Do not put covered groups into AD

2)      Modify AD permissions

 

The latter category usually fall into two methods, which for a while were referred to on the Hi-Ed list as “The Stanford Method” and “The University of Florida” (aka “The less insane”) method.

 

Stanford Method:

User objects:

We modified the default DACL on user objects in the schema so that user accounts have an empty ACL by default (Only inherited ACEs apply). This removed Authenticated Users from being able to read anything on any user account. We then re-added the ability to see yourself and just enough of any other user to be functional (cn, objectClass, objectGuid and a few more are required to add a user to a group, etc.) as inherited ACEs. There are some permission sets that are added for LDAP services based on approval by data owners (Read Email address, Read Name, etc.). If a user chooses to be visible, then a process runs and sets explicit ACEs on each individual user object to reflect their elections. This covers memberOf among other attributes.

 

Group objects:

Each visible group object has 1 member – a hidden group that contains the actual membership.  (Though I am looking to phase this out in favor of University of Florida’s suggested method of using out-of order ACLs implemented via mixing implicit DENY and explicit ALLOW ACEs on “member”)

 

Note: Not being able to read memberOf is actually considered a little bit of a bonus since we have multiple domains – Since memberOf is a “back-link” attribute, it only contains memberships from the same domain as the user. Having it not available keeps people from relying on it – there are better ways for an application find what groups a user is in.

 

-Ross

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of michele mueller
Sent: Tuesday, March 26, 2013 8:05 AM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server?

 

I would also be interested in knowing the solution to this.  We are getting the same request to populate course groups in AD, but we are concerned with FERPA and the memberof attribute

Michele Mueller
 


Chuck Phillips wrote:

Interesting topic,   We are exploring creating goups for class lists.  However, the memberof attribute in each persons AD entry exposes group membership.     Putting read rights on the memberof attribute will,  we are pretty sure, break more things than we are willing to sacrifice.   Exposing the memberof attribute is borderline FERPA violation since, in theory, an AD knowledgable student could stalk another student by seeing which classes they are enrolled in.      How are others dealing with class groups and the memberof attribute relating to FERPA?   Chuck Phillips chuckp@unm.edu   ________________________________________ From: Identity Management Constituent Group Discussion list [IDM@LISTSERV.EDUCAUSE.EDU] on behalf of Belleville-Rioux, Vincent [rioux.vincent@UQAM.CA] Sent: Tuesday, March 26, 2013 7:56 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server?   John, your setup is interesting.  Out of curiosity, are you using AD as the topmost source of authentication or are you also using an identity manager to synchronize directories?   Regards,   Vincent   -----Message d'origine----- De : Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] De la part de John Goodman Envoyé : 26 mars 2013 09:42 À : IDM@LISTSERV.EDUCAUSE.EDU Objet : Re: [IDM] Anyone using Active Directory as sole (enterprise) directory server?   Here at UW-Milwaukee we recently implemented Ferpa protections within our Active Directory environment.  Like Vincent mentioned below, we modified the ACL's on protected accounts to prohibit Authenticated Users.  Service owners requiring access to these protected accounts are required to fill out an "access to services" form that is submitted to our Registrar's office for approval.  Once approved, the service account is added to a security group that is permitted to access the protected accounts.   I would say that the process we have in place has worked quite well, but not without some initial issues.  Even with proper communication the behavior of these protected accounts still confused some distributed administrators which created some un-necessary troubleshooting.   Some initial "gotchyas" were... - OSX requires read access to the General and Public attribute sets to allow for a user to authenticate. - Distributed administrators are unable to add these users to security groups without being added to the "ferpa administrator" group themselves   If anyone is interested in a more detailed explanation of our current configuration, please feel free to contact me.   John Goodman Identity and Access Management UW-Milwaukee Cunningham Hall B193 414-229-6577    
Thank you all for the excellent information and responses!

Regards,
Mike

Close
Close


EDUCAUSE Connect
View dates and locations

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

EDUCAUSE Institute
Leadership/Management Programs
Explore More

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.