jean-Noël Chardron wrote: > Rich Megginson wrote: > >> jean-Noël Chardron wrote: >> >> >>> hello, >>> >>> In my company, the AD server that is sync with a 389 directory server >>> will be changed by a new one (because the actual AD is used and old and >>> not eternal) >>> In the documentation >>> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Windows_Sync.html >>> I don't find the possibility to edit the name of the AD in the Sync >>> agreement in the console of 389. >>> I suppose that I need to delete the previous sync agreement and create a >>> new sync agreement with the new AD server. >>> So I have question about this process : >>> 1/ does the deleting sync agreement delete the data in the 389 directory >>> server? >>> >>> >>> >> No. >> >> >>> 2/ Do I need to create the new sync agreement before to delete the >>> previous or vice versa ? >>> >>> >>> >> You should first delete the previous, then create a new one. >> >> >> >> > Thanks for your answer. > Ok I delete and create a new one, and the result diff in the dse.ldif is : > # diff dse.ldif-old /etc/dirsrv/slapd-aragon/dse.ldif > 1386,1387c1386,1387 > < dn: cn=synchroAD, cn=replica, cn="ou=DR15,dc=ad,dc=dr15, dc=cnrs, > dc=fr", cn=m > < apping tree, cn=config > --- > > dn: cn=sync AD, cn=replica, cn="ou=DR15,dc=ad,dc=dr15, dc=cnrs, > dc=fr", cn=map > > ping tree, cn=config > 1390,1391c1390,1391 > < description: Synchronisation de l'AD de zebigbos > < cn: synchroAD > --- > > description: Synchro de l'ad avec 15SRVAD > > cn: sync AD > 1398c1398 > < nsDS5ReplicaHost: zebigbos.dr15.cnrs.fr > --- > > nsDS5ReplicaHost: 15srvad.ad.dr15.cnrs.fr > 1405,1418c1405,1407 > < modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > < createTimestamp: 20090611082927Z > < modifyTimestamp: 20100309145141Z > < nsds7DirsyncCookie:: > TVNEUwMAAAAV2xUImL/KAQAAAAAAAAAA2AEAAEOdAQAAAAAAAAAAAAAA > < > AABDnQEAAAAAAF9Rvn8HIWhOkUunH1LEMI8BAAAAAAAAABMAAAAAAAAAP/yMQ9AY7UWBZKfqbuIU > < > FmOXBwAAAAAAcrpIZcFNk0Otnh6jbg9QyIpwAAAAAAAAPQPjcJTpIEqk0awfWJhXt2BgAAAAAAAA > < > H4lEdfD5sE64GX+P1H8ETKa4CgAAAAAA3eOpfBS2Y0SrHFxTGISQOWqjHQAAAAAAX1G+fwchaE6R > < > S6cfUsQwj3adAQAAAAAAMyQ+hzgHmEiQuVpgulHJPC7FAAAAAAAAjGl+keyEek6GUn9KEi5c/q5H > < > AwAAAAAAZQa0nmx01UWqsytWckzlI0L+AQAAAAAAGazXqygJLEu86IxNUsGY2MSQAAAAAAAASyZd > < > sjx5Gky9OuOXcthaWicwAAAAAAAAqFEJtdSpsUK/43VeNnP+pY1AAAAAAAAA9dvBuRpx7UmWD+rC > < > 3w41+V0gAQAAAAAACH3fwPa/UkqSacbwY+m5+vc8AAAAAAAA7sbo9Ib5yEWsNYVHjhdo4ifTQAAA > < > AAAAE4SK9SytXEWdF32IwQsoqvaOCQAAAAAAnASF+yUqj0qpBIkYHYdWatUcAAAAAAAAj29b/BZ1 > < 1Uec6sfIJNFYG2JAAAAAAAAAPIF+/pnmE0qhCSz9C438n1cVBwAAAAAA > < nsds50ruv: {replicageneration} 4a2e7e020000ffff0000 > --- > > modifiersName: cn=directory manager > > createTimestamp: 20100310101217Z > > modifyTimestamp: 20100310101217Z > > > So I have few more question : > the nsds7DirsyncCookie is not present in the new sync agreement , may be > because I don't initiate a full resynchronisation. right ? > Right. > If I initiate a full resynchronisation, does the ldap server keep the > user NT password and the same ntUniqueID in the base ? > What attribute is the user NT password? ntUniqueID - not sure, but as long as the object GUID doesn't change in AD, the unique ID shouldn't change either If you are worried about losing any data in the DS, you should first make an LDIF dump (db2ldif) or a backup. > > > > > > > >> Alternately, you could stop the server, and edit the dse.ldif file >> directly, and just change the name of the AD host. That might work - >> the DS uses the AD DirSync control to sync with AD - if the hostname/IP >> address is part of the cookie, then incremental sync from AD to DS might >> fail - in that case, you would have to re-init the sync (which is what >> you would have to do anyway if you delete and add the agreement). >> >> >>> >>> thanks, >>> >>> >>> >>> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> > > > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
