Reprt: April 12, 2011 By Erick Engelke I have rganized my tasks arund tw majr prblems: 1. Define the new active directry a. Dmain Name Service fr the dmain - cmplete b. Dmain layut, structuring f Organizatinal Units almst cmplete, wrking clsely with Manfred and sn with Sean Masn. 2. Planning the migratin a. Inventry f accunt types/needs - cmplete b. Investigating migratin tls Manfred and I have been studying and will sn test, als getting qute frm utsurcers. c. Planning all aspects f the migratin when t d servers, etc. Still quite incmplete Dmain Name Service Tgether with the AD-DNS subgrup, I cnducted an analysis f the existing dmain name service in Nexus (MS Dynamic DNS, zer tuch, autmatic) and ADS use f the campus DNS. The cmplete ntes are available at http://www.eng.uwaterl.ca/~erick/ad/dns.htm Reslutins: IST has sufficient infrmatin t prceed with the DNS RFP Nexus shuld cntinue t use its wn nn-authritative DDNS indefinitely, it ffers real benefits Althugh this may seem like tw independent DNS systems, they are tied tgether by IT staff recgnizing the authrity f the netwrk grup s DNS registratin system. Als, sme bservatins were made abut fully qualified dmain names (FQDN) causing prblems and the future implicatins f remving CNAMEs may limit future cnslidatin. These bservatins may be useful t the nging design f campus DNS. Inventry f Accunts In rder t d a successful migratin f cmputer accunts frm tw dmains int ne and have it managed by WatIAM, we must have a few details: Where d the accunts exist tday?
If smene is active in ADS but nt Nexus, we shuld prbably mve him, preserving hme directry, passwrd, prfile infrmatin, etc. If a persn is active in Nexus t, it appeared we shuld merge his accunts. Des the persn have data n sharepint, can it be brught frward? Des the user have a hme directry n ne system mve that frward. If the user has hme directries n bth systems which takes precedence. Migrate the grups frm ADS t nexus Migrate nn-lgin userids Migrate lgin-type userids Update the grups again Migrate many file-type server resurces (s ne can lg in with either nexus r ads) Migrate users+wrkstatins fr thse wh lg in Migrate remaining servers First, sme facts. Bth ADS and Nexus have sme accunts nt registered in WatIAM, and accunts nt in the ther dmain.
One may wnder why there are s many accunts in ne dmain and WatIAM but nt the ther dmain. Nexus and ADS bth have all current students ADS has all faculty and staff, whereas Nexus des nt have all f them ADS and Nexus each have sme guests, instructin accunts, etc. which are nt created in the ther Nexus has sme accunts wh are n lnger active frm a WatIAM perspective and n lnger have ADS accunts. These wuld include graduates frm the last few years wh might nt have been purged. Cmments: We are wrking n the assumptin that all user accunts are assigned t their WatIAM wner. S if there is an s3james, we assume it is used by the right persn. This becmes less reliable when we cnsider accunts created utside WatIAM. Of the 7310 accunts nt in WatIAM, nly 515 were active between Jan 1,2011 and nw (April 7) (many thers were camp accunts Arts and Engineering camps). That was 270 in nexus and 252 in ADS. 224 f them are bang accunts. 291 are nt bang accunts. Actin Items fr userid being valid watiam: Identify 196 current nexus accunts utside WatIAM, add them t WatIAM r delete them(incmplete) Identify 95 current ADS accunts utside f WatIAM,. (task nt assigned t anyne) Understanding Accunt Migratin In a Windws envirnment, every cmputer accunt, every cmputer, and every grup has a Secure Identifier r SID. The SID is a 128 bit number which is statistically unique in the wrld, it als cntains a prtin which identifies the dmain in which it resides. SIDs are used t identify the user r cmputer, and als t grant permissins in Access Cntrl Lists r ACLs, which are present n files, printers, databases, etc. Due t the way SIDs must be created, we cannt cpy the ADS SIDs int Nexus accunts, and anyways, mst active users already have Nexus SIDs t. erick@nexus.uwaterl.ca has the SID: S-1-5-21-1417001333-651377827-839522115-2355 and erick@ads.uwaterl.ca has the SID: S-1-5-21-1417001333-1580436667-682003330-10595 If erick@ads can successfully mve t nexus, we need t change all the references t pint t a nexus SID. Hwever, t make a transitin pssible, we will actually change the resurces t pint t bth SIDs
fr the transitin, and then later remve the ADS SID when it is n lnger needed as the dmain is eventually decmmissined. In Active Directry, the SID f an accunt is usually stred in the bjectsid field. Hwever, there is als an ptinal sidhistry field which can hld a legacy SID frm a prir dmain. S, after we assign Erick@nexus the sidhistry entry : S-1-5-21-1417001333-1580436667-682003330- 10595, and disable SID filtering, and take a few ther steps, we can grant erick@nexus access t the lder resurces. When we update the reurces t use the new SIDs, they will claim t be wned by the @nexus accunt. Fr example, SharePint displays the creatr f files. First we migrate users, then we migrate resurces t pint t the new users. After that, SharePint will pint t the Nexus user even thugh the ADS user had riginally created the file. A Few Cmments SID Migratin The easiest way t mve ADS users t Nexus is nt the best way. It wuld invlve just creating new accunts with new SIDs, then abandning user prfiles but als ging thrugh migrating file servers and adjusting the resurces t pint t the new SIDs. Users wuld be displeased. The prfile cntains many smewhat useful settings, including the user bkmarks fr Internet Explrer. There are three categries f peple we will need t migrate: A. Staff wh wrk primarily in ADS tday 1,548 peple 1,221 have raming prfiles (65 are already in nexus) 327 dn t have raming prfiles (75 are already in nexus) B. Peple wh casually use ADS with SIDs (eg. sharepint nly) 11,970 C. C-ps emplyed by UW wh use ADS 287 n April 8 th Grup A fllws standard migratin rules. The prcess is well dcumented using standard Micrsft tls (Active Directry Migratin Tl r ADMT), such as wuld be dne after tw cmpanies merge r after an acquisitin. The tw subgrups with and withut raming prfiles require slightly different strategies. Frm Grup A, the 65 and 75 peple already in nexus are a prblem. We have t d extra wrk t keep their data in bth dmains. Grup B is a little bit mre cmplicated. Many in this grup already have existing Nexus accunts and we d nt want t disturb them. ADMT can be used with a merge ptin, but this is prbably nt necessary and Micrsft advised cautin with this strategy. Instead, it might be easier t simply update the sharepint server s file assciatins that wuld prbably take a day.
Grup C are the mst cmplicated at first glance. Mst have hme directries and prfiles in bth dmains, s the questin arises as t hw we merge, which shuld have pririty? They cannt be easily autmated withut causing disruptin either fr academic purpses (their nexus hmedirs may be needed fr WatPD curses during c-p term), r their ADS drive (they might need thse files every day they wrk). Since grup C has less than 300 users, and they wrk nly fur mnths, we might d them n a term bundary. Other suggestins are welcmed!!! Plan fr Migratin f Accunts I really want t try migrating grups and users in the test dmains. Manfred has been trying t set that up. He has made arrangements with Hn and als the IST security team, but it s nt quite ready fr testing yet. Our next steps are: Create necessary trusts between ADS and nexus Disable SID filtering between the dmains (temprarily reduces security smewhat, but is a necessary step f migratin) Install the ADMT tl n a nexus dmain cntrller (necessary fr SID retentin) Set up the required migratin accunts. Migrate ADS grups Migrate grup A Migrate grup B wh dn t already have Nexus accunts Deal with grup C. Red the grups t include all members Once thse steps are cmplete, hpefully by early May, we can begin transitining resurces like sme servers and then wrkstatins.