ADTF 2016 05 04
buss, chartier, dattilo, estradar, erinmcd, fredrick, gwilliam, hharris, hoekstra, jdister, jlampe, jtanner, kimn, mmoore, rjbubon, rwallis, sandoval, wderman
- Authenticating OS X and Linux against AD (Road blocks?)
- OU uniformity
- Password Complexity/Reset Portal Demonstration
- PeopleSync to AD update
- Open Discussion
May the 4th be with you and be prepared for Revenge of the 5th!
Based on the last meeting, a check on the progress on getting everyone to authenticate workstations to AD.
FANDA reported that all workstations are authenticating to AD. Heather also reported that the Library/IIS workstations are all authenticating to AD as well.
We don’t have an update or plan for Unidata workstations. UNIDATA currently has a job posting to hire a new systems admin which could give them more resources for this effort. The possibility of UNIDATA becoming more integrated with CIT AD would also help this process.
The question on whether everyone will be able to get their workstations authenticating to AD for August was raised and the consensus is everyone on schedule.
ACOM has posted the Joining CentOS7 to Active Directory doc to the ADTF shared directory on Google Drive for reference.
The question was raised about other versions/flavors of Linux with AD integration. There will be some differences, but the PAM method should be the most straight forward easiest to deploy.
Some discussion on the need for a primary field in PeopleDB/AD for database consistency. We may need to address this in the future, but the goal of this first step was to get paid employee user accounts in AD. A new HRIS system for onboarding in the future may help us determine the path to achieve consistency between user databases and may force the need to correlate the data. It was emphasized that a join field would make transitioning between DBs much easier.
It is clear that additional account auditing, etc. may be needed, but that is not in the near term scope of the project. Data integrity is still an issue. Some cleanup will happen in People DB, but data consistency for the mapped fields will be a positive result from the PeopleSync to AD workflow.
The question was raised about joining macs to AD and if it would be better to have a centralized OU for Macs? While it is possible and something we can consider, keeping the current process having Macs exist in the OU for the Lab that maintains them is the consensus.
There is effort to centralize some of the processes that affect all divisions when it makes sense. An example being the EM groups created for each division. The script logic to maintain these groups and update membership when changed is problematic. It will probably make more sense to populate all EM users into one CIT-EM group if possible for queries on group membership.
The question was raised on where the effort to centralize processes is being facilitated. As ideas come up the ADTF would be to the proper forum to share with the group. The ADTF shared directory on Google Drive the best place to post documentation for reference or discussion.
The topic of OU uniformity was brought up and the CIT Naming Conventions and OU Design was reviewed to look at best practices.
The idea was brought up about a having a common OU for new disabled accounts. For EM users is it would be straight forward, but start to get complicated when other employee types are integrated. It makes sense to maintain separate disabled user OUs but we need to standardize the naming and location of the OU for all Labs.
For efficiency, the decision was made to update the OU mappings for PeopleSync all at once after the OU cleanup is complete. The tentative date for this is June 13th. Ramsey will coordinate this effort. The existing disabled OUs are not to be changed until then as not to affect the process of creating new accounts via PeopleSync.
Some discussion about the workflow of on-boarding and off-boarding in UCAS accounts/passwords. Nothing is changing with this process yet. SEG will continue with the current process.
Again, do not change the disabled OUs yet, we will announce a date (probably June 13th) and coordinate efforts.
The remaining time was spent with a demonstration of Anixis Password Complexity and Reset software deployed in the test domain. Most questions were answered while going through the demo. One concern was how the enrollment data is stored and it was confirmed the data is stored encrypted. Auditing of the system was brought up and it was determined that the system does gather the IP address when the system is used and all changes, resets and unsuccessful attempts are audited. Because it is a SQL database, it may be possible to tie in additional monitoring.