The AD Connector will not be implemented as phase 1.
Our current thinking is that this will be yet another GTC instead of the OOTB connector due to implementation differences. Primarily, we believe the SAMAccountName must equal the User Login. However, our AD's SAMAccountName is our Net ID, and the User Login is our Yale UPI.
Field Mappings (from Exchange Provisioning tool:
' AD Field Primary Student Dependant Confidential
' sAMAccountName NetID NetID NetID NetID
' userPrincipalName * ... ... ...
' * Set to published email address. If no address published, use netid@yale.edu
' * If not in production, substitute @yale.local instead of @yale.edu
' uuid UPI UPI null UPI
' mail published email address ... mailbox
' givenName First ... null null
' initials Middle Initial ... null null
' sn Last Name ... null null
' displayName Last, First ... netID NetID
' title Directory Title * null null null
' * Limit to 36 characters.
' description Directory Title null null null
' employeeID hr_person_id ... null null
' department primary_org_name null null null
' company * ** ** **
' * Yale Univeristy; primary org name
' ** Yale University
' physicalDeliveryOfficeName office_location null null null
' streetAddress * ** null null
' * Office Street Nbr + Office Street
' ** If Grad, use grad_student_addr_line1 + line2
' ** If Undergrad, use campus address
' postOfficeBox null * null null
' * If Grad, null
' * If Undergrad, yale_station
' l Office City * null null
' * If Grad, grad_student_city
' * If Undergrad, New Haven
' st Office State * null null
' * If Grad, grad_student_state
' * If Undergrad, CT
' postalCode Office Zip * null null
' * If Grad, grad_student_zip
' * If Undergrad, 06520
' telephoneNumber Office Phone * null null
' * If Grad, use grad_student_phone
' * If Undergrad, use campus_phone
' Yale-Mac-Home /Users/netid ... ... ...
' msExchHideFromAddressLists FALSE ... ... TRUE
' mxExchPoliciesExcluded {26491cfc-9e50-4857-861b-0cb8df22b5d7} for conf. people.
'
adUserPrincipalName = dbResults("userPrincipalName")
adUuid = CSTR (dbResults("uuid"))
adGivenName = dbResults("givenName")
adIinitials = dbResults("initials")
adSn = dbResults("sn")
adDisplayName = dbResults("displayName")
adEmployeeID = CSTR (dbResults("employeeID"))
adYaleMacHome = dbResults("Yale_Mac_Home")
adMail = dbResults("mail")
adDescription = dbResults("description")
adTitle = dbResults("title")
adDepartment = dbResults("department")
adCompany = dbResults("company")
adPhysicalDeliveryOfficeName = dbResults("physicalDeliveryOfficeName")
adStreetAddress = dbResults("streetAddress")
adPostOfficeBox = CSTR (dbResults("postOfficeBox"))
adL = dbResults("l")
adST = dbResults("st")
adPostalCode = CSTR (dbResults("postalCode"))
adTelephoneNumber = dbResults("telephoneNumber")
IF dbResults("confidential_flag") = "N" THEN
adMsExchHideFromAddressLists = FALSE
ELSE
adMsExchHideFromAddressLists = TRUE
END IF
The above needs to be translated from OIM fields to AD Fields and the new confidentiality rules applied.
Need to apply SOM rules as well.
I believe the following reflects all rules:
As we discussed in today's meeting, the following fields WILL be
updated by the Daily AD update, even if the person is in the SOM OU:
* sAMAccountName
* Company
* DisplayName
* employeeID
* givenName
* Initials
* l
* physicalDeliveryOfficeName
* postalCode
* sn
* st
* streetAddress
* telephoneNumber
* title
* userPrincipalName
* Yale-Mac-Home
* UUID
The following fields WILL NOT be modified by the daily update if the
person is in the SOM OU.
* department -- Populated by SOM from an SOM database due to HR
data limitations.
* description -- Manually managed by SOM.
* mail -- Excluded because it is mail related.
* mailNickName -- Excluded because it is mail related.
* msExchHideFromAddressLists -- Excluded because it is mail related.
* proxyAddresses-- Excluded because it is mail related.
-------------
NOTES:
* UUID is new to the process, and will be set to the Yale UPI, even
if the person is confidential.
* givenName will be the preferred name if one is present, otherwise
it will be the first name.
* Display Name will use the preferred name if available, otherwise
it will use the first name.
* IMPORTANT: Before the daily update can go live, central campus
users using the SOM servers need to move to the central campus
servers. Otherwise, we will update their mail addresses with the
incorrect values.
* The other conversions regarding what to put in the proxyAddresses
(for connect exchange users only) will be decided pending the results
of our alias addressing tests.
Need to allow SOM to use a nickname for students or get SFAS to relax thier requirement.
Comments (1)
Dec 02, 2008
Rod Gustavson says:
Things to consider regarding SOM usage of the AD.\\ From: Wieler, Kenneth Sent: ...Things to consider regarding SOM usage of the AD.
From: Wieler, Kenneth
Sent: Tuesday, April 15, 2008 11:33 AM
To: Radcliffe, Adriene
Cc: Palmeri, Diane; Ergunay, Tolga
Subject: AD Properties
Hi Adrian,
I was told you are the person to talk to about the whole AD population process. I know Rod and company are doing the programming but I want to raise this to the higher management/ the project leader. We have some situations with the AD population and I want to see how we can resolve them. If we can do it at the university level that would be ideal or SOM can handle them for the users in the SOM OU. The following fields are currently not updated for users in the SOM OU. Below is an explanation of which fields, why it is excluded and what we require:
Display Name
When we turned the Display name update process on for the SOM OU, the Students who have a preferred name were all reverted back to their First Name. From what I understand a decision was made to not use the preferred name for students. We need to use this for our students.
The other issue here is we have a faculty member whose name is Sudhir Karunakaran. He goes by K. Sudhir (Sudhir, K in the GAL), all his papers are published this way and everyone know him this way. When we put the process of last name, first/pref name no one could find him in the address book. This causes major problems and confusion.
My thoughts are that for the students, we have the central update process take care of the names for our students by using the preferred name if it exists. If you don't want to do that for the rest of the University, just do it for the accounts in the SOM OU. I am not sure if the central code will be able to handle Sudhir's case. Could we have a field in Oracle for a display overwrite or something?
Department
We do not have this updated by central because we use the department for the internal SOM department (i.e. IT, CDO, SAS, etc). With the central update process all SOM people would have a department of SOM which does not help anyone. We use this for dynamic lists and such. Central agreed to put "Yale University - 'department'" in the Company field so we can query that field but there is no means to put the actual department in for the individual schools.
We also use this field to distinguish our students by program and year (i.e. SOM MBA 2008, SOM MBA-e 2008 ...) There is no mechanism to have the central process put this data in for our students.
Is there a field in Oracle we can use to store this data and have the central process update this field?
Company
As I said above, the central update process uses "Yale University - 'department'" for the company field. It works great for staff and faculty but for some reason the students are not given a department so in AD they just have "Yale University". We are trying to have a dynamic list for all SOM people so I would need this populated with the same "Yale University - Sch of Management" that staff and faculty are given so there is an accurate list of SOM people.
I think if just read the curriculum filed that PH shows we can populate that information. As far as I understand it that shows their primary enrolment. We can use this to populate the proper company so we can have a accurate and dynamic list of SOM people. The thing I am not sure of would be the joint degrees, I don't know how the curriculum field is populated.
There are a couple of other exchange fields but I need to address them separate and figure out all the options. These fields are the initial ones that are cause problems here at SOM and we are seeking solutions. If possible we would like to keep these in the same place and update process as the rest of the university, but if that is a problem for central we can update our users for these fields. I realize timing with everything happening but I want to raise these to your attention and figure out what options we have. We are currently moving forward with our update of these fields until we can work something out.
I would have to assume this is not going to be isolated to SOM and others would probably like the same things.
Please let me know how to proceed and if these changes are able to be done and the university level.
Thanks
Ken