Even though we have integrated authentication for accounts, user provisioning still needs to occur in every system independently.
The Windows IT staff takes care of this. At the time of writing, all users are deleted and recreated at the beginning of every school year. Sysadmins (starting with the graduating class of 2006) are moved into a separate ou (organizational unit) before this occurs and will have their accounts preserved, but passwords are still subject to expire annually.
The update_nssldap.sh script (authored by William Yang; see NSS LDAP) will handle user provisioning in AFS and NSS LDAP. It depends on Identity Synchronization for Windows (ISW) to be working properly. Because of the way AD accounts are recreated every year, it is recommended to follow this procedure when it is time to create accounts every fall. The idsync command below is part of ISW and is located in /opt/SUNWisw/bin on the ISW server (usually the primary NSS LDAP server). Not all required arguments to the idsync command are listed here.
- Stop ISW synchronization (idsync stopsync)
- Reassociate accounts (idsync resync)
- Restart ISW synchronization (idsync startsync)
- Run update_nssldap.sh script (make sure you've read the section on this script in NSS LDAP!)
If accounts are not deleted and recreated in AD anymore, or there are only a handful of new accounts added that need to be provisioned in NSS LDAP and AFS (for example, staff or late registering students), just run the update_nssldap.sh script (you should still read the relevant section of NSS LDAP).
This is handled by a data import module, currently "newimport." A SASI dump is involved for students. Student data import must currently be handled by a member of the IT staff or the sysadmin sponsor due to privacy issues with student data in intranet. New staff are individually added by Mr. Washer using an interface in the newimport module.
/opt/zimbra/scripts/ldap_mail.php (authored by Lee Burton based on the previous version used for the old Postfix/Squirrelmail system on cronos) will update accounts and account attributes (including quota) based on data in AD. It should be run as the zimbra user (su zimbra). Currently, accounts disabled or deleted in AD are locked in Zimbra.
In the event that this script fails to execute zmprov commands successfully, you may wish to try changing the zmprov commands to run with the -l option (use LDAP instead of SOAP protocol). To do this, there are only two command pairs which need their commented status toggled in the script (search for "zmprov -l".)
There are two locations in this script where accounts that should be preserved are specified. These may include Zimbra internal accounts, special purpose accounts not registered with AD, etc.