configuring SSL for windows replication
by solarflow99
For self signed certs, as I understand it, the 389 supplier that has the CA
must create a server cert for the windows host? How can this cert be
exported/imported since windows doesn't use pk12util? Has anyone set this
up, and can say the steps on windows 2008? I see there are many options for
installing IIS and Microsoft CA.
Thanks,
13 years
- 3
- 2
extra IPv6 traffic wasting file descriptors
by Brian High
Hi 389 users,
After searching through bugzilla, list archives, wikis, blogs, etc., I am still puzzled.
We have 389 running on a single-homed RHEL5.6 (389-ds-1.1.3-4). (We are getting ready to upgrade in about a week to the latest version.)
We had disabled IPv6 in the interface setup (i.e. NETWORKING_IPV6=no in /etc/sysconfig/network), but recently found the following:
1. The OS still has IPv6 enabled (ip6tables running and interface has "inet6 addr" in ifconfig).
2. Since we installed it last year, 389 has been listening on "all interfaces".
3. Even though there are no incoming 389 requests via IPv6, our 389 server opens lots of IPv6 connections.
4. This has created a file descriptor shortage in the past. A quick fix was to restart dirsrv.
5. In researching how prevent it, we did all of the related performance tunes as recommended.
6. But, ultimately, we see in netstat and lsof that open IPv6 connections increase each day.
7. Even with ip6tables dropping all IPv6 traffic, we still see this increase in connections.
8. Considering we do not run IPv6 here at all, and the firewall blocks it anyway, this was surprising.
9. We took more steps to disable IPv6 in RHEL and configured 389 to only listen on the one IPv4 address.
So, while it is now fixed, we cannot help but wonder, why 389 is trying to make these extra IPv6 connections. The number varies throughout the day, relative to load, so it must be in response to real requests on IPv4 somehow. Is 389 trying to reply to requests on *both* IPv4 and IPv6 networks, even for requests from IPv4?
Any leads in understand this puzzle will be greatly appreciated.
Mystified,
Brian High
13 years
- 2
- 1
Re: [389-users] Windows Sync Agreement Help
by Albert Teh
*Great News*.
After talked to the AD Administrator, assigned the user: mailadm as a
administrator. The Windows Sync is working. Thank you all for the great
help.
My next step is to get the Password Sync working.
*Need help again:* 1) need to remap the attributes synchronizing from the AD
to the DS.
Is there any plugin for this process?
2) What password attribute is using on the DS for
the LDAP client's authencation?
I do not find the attribute: userPassword from
the AD to the DS
after the SYNC.
Thanks again for all the help.
Albert
On Fri, Jun 3, 2011 at 3:37 AM,
<389-users-request(a)lists.fedoraproject.org>wrote:
> Send 389-users mailing list submissions to
> 389-users(a)lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> or, via email, send a message with subject or body 'help' to
> 389-users-request(a)lists.fedoraproject.org
>
> You can reach the person managing the list at
> 389-users-owner(a)lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 389-users digest..."
>
>
> Today's Topics:
>
> 1. ds-admin script/package (Danny Wall)
> 2. Re: ds-admin script/package (solarflow99)
> 3. Re: ds-admin script/package (Danny Wall)
> 4. Re: ds-admin script/package (solarflow99)
> 5. Re: ds-admin script/package (Danny Wall)
> 6. Re: ds-admin script/package (Rich Megginson)
> 7. Re: Windows Sync Agreement Help (Carsten Grzemba)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 Jun 2011 16:40:37 -0400
> From: Danny Wall <dwall72(a)gmail.com>
> Subject: [389-users] ds-admin script/package
> To: 389-users(a)lists.fedoraproject.org
> Message-ID: <BANLkTi=kzFoCphzp1a1ckniuwumRTUnH-w(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I am setting up three RHEL 6 servers and am unable to find the packages or
> scripts to install the admin console. In CentOS 5.5 and the 389 project,
> the
> packages are available, and I see references to setup-ds-admin.pl in RHEL
> 6
> documentation and in searches. I have the dirsrv package installed and a
> couple LDAP instances configured, but I have to use generic LDAP browsers
> for administration and can not configure password policies, etc. that
> appear
> to require the admin console or web page.
>
> Can anyone point me to the missing link?
>
> Thanks
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/c...
>
> ------------------------------
>
> Message: 2
> Date: Thu, 2 Jun 2011 16:56:52 -0400
> From: solarflow99 <solarflow99(a)gmail.com>
> Subject: Re: [389-users] ds-admin script/package
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Message-ID: <BANLkTinV443CJfUCBnXeoQXfeh2uTWAPhw(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> There are several RPM's involved, what repo and yum command did you use?
>
>
> 2011/6/2 Danny Wall <dwall72(a)gmail.com>
>
> > I am setting up three RHEL 6 servers and am unable to find the packages
> or
> > scripts to install the admin console. In CentOS 5.5 and the 389 project,
> the
> > packages are available, and I see references to setup-ds-admin.pl in
> RHEL
> > 6 documentation and in searches. I have the dirsrv package installed and
> a
> > couple LDAP instances configured, but I have to use generic LDAP browsers
> > for administration and can not configure password policies, etc. that
> appear
> > to require the admin console or web page.
> >
> > Can anyone point me to the missing link?
> >
> > Thanks
> >
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/5...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 2 Jun 2011 17:01:36 -0400
> From: Danny Wall <dwall72(a)gmail.com>
> Subject: Re: [389-users] ds-admin script/package
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Message-ID: <BANLkTimNg3HGJZgvLO6MdRB-LiQBAsfAMw(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I first tried to the default rhel 6 repo then tried adding the epel 6 repo.
>
> Thanks
> On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99(a)gmail.com> wrote:
> > There are several RPM's involved, what repo and yum command did you use?
> >
> >
> > 2011/6/2 Danny Wall <dwall72(a)gmail.com>
> >
> >> I am setting up three RHEL 6 servers and am unable to find the packages
> or
> >> scripts to install the admin console. In CentOS 5.5 and the 389 project,
> the
> >> packages are available, and I see references to setup-ds-admin.pl in
> RHEL
> >> 6 documentation and in searches. I have the dirsrv package installed and
> a
> >> couple LDAP instances configured, but I have to use generic LDAP
> browsers
> >> for administration and can not configure password policies, etc. that
> appear
> >> to require the admin console or web page.
> >>
> >> Can anyone point me to the missing link?
> >>
> >> Thanks
> >>
> >>
> >> --
> >> 389 users mailing list
> >> 389-users(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/7...
>
> ------------------------------
>
> Message: 4
> Date: Thu, 2 Jun 2011 17:11:13 -0400
> From: solarflow99 <solarflow99(a)gmail.com>
> Subject: Re: [389-users] ds-admin script/package
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Message-ID: <BANLkTikoc5p3WRQSoJO3toL28-wkzc+anQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> good, epel is the one to use. Did you use yum install 389-ds ? that will
> pull in the whole thing.
>
>
>
>
> 2011/6/2 Danny Wall <dwall72(a)gmail.com>
>
> > I first tried to the default rhel 6 repo then tried adding the epel 6
> repo.
> >
> >
> > Thanks
> > On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99(a)gmail.com> wrote:
> > > There are several RPM's involved, what repo and yum command did you
> use?
> > >
> > >
> > > 2011/6/2 Danny Wall <dwall72(a)gmail.com>
> > >
> > >> I am setting up three RHEL 6 servers and am unable to find the
> packages
> > or
> > >> scripts to install the admin console. In CentOS 5.5 and the 389
> project,
> > the
> > >> packages are available, and I see references to setup-ds-admin.pl in
> > RHEL
> > >> 6 documentation and in searches. I have the dirsrv package installed
> and
> > a
> > >> couple LDAP instances configured, but I have to use generic LDAP
> > browsers
> > >> for administration and can not configure password policies, etc. that
> > appear
> > >> to require the admin console or web page.
> > >>
> > >> Can anyone point me to the missing link?
> > >>
> > >> Thanks
> > >>
> > >>
> > >> --
> > >> 389 users mailing list
> > >> 389-users(a)lists.fedoraproject.org
> > >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> > >>
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/d...
>
> ------------------------------
>
> Message: 5
> Date: Thu, 2 Jun 2011 17:14:59 -0400
> From: Danny Wall <dwall72(a)gmail.com>
> Subject: Re: [389-users] ds-admin script/package
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Message-ID: <BANLkTin08GVsHrwh6EZV0ZdchXUKcwchsw(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I may have used 389 base. I will try it later without the base. Thanks
> On Jun 2, 2011 5:11 PM, "solarflow99" <solarflow99(a)gmail.com> wrote:
> > good, epel is the one to use. Did you use yum install 389-ds ? that will
> > pull in the whole thing.
> >
> >
> >
> >
> > 2011/6/2 Danny Wall <dwall72(a)gmail.com>
> >
> >> I first tried to the default rhel 6 repo then tried adding the epel 6
> repo.
> >>
> >>
> >> Thanks
> >> On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99(a)gmail.com> wrote:
> >> > There are several RPM's involved, what repo and yum command did you
> use?
> >> >
> >> >
> >> > 2011/6/2 Danny Wall <dwall72(a)gmail.com>
> >> >
> >> >> I am setting up three RHEL 6 servers and am unable to find the
> packages
> >> or
> >> >> scripts to install the admin console. In CentOS 5.5 and the 389
> project,
> >> the
> >> >> packages are available, and I see references to setup-ds-admin.pl in
> >> RHEL
> >> >> 6 documentation and in searches. I have the dirsrv package installed
> and
> >> a
> >> >> couple LDAP instances configured, but I have to use generic LDAP
> >> browsers
> >> >> for administration and can not configure password policies, etc. that
> >> appear
> >> >> to require the admin console or web page.
> >> >>
> >> >> Can anyone point me to the missing link?
> >> >>
> >> >> Thanks
> >> >>
> >> >>
> >> >> --
> >> >> 389 users mailing list
> >> >> 389-users(a)lists.fedoraproject.org
> >> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >> >>
> >>
> >> --
> >> 389 users mailing list
> >> 389-users(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/7...
>
> ------------------------------
>
> Message: 6
> Date: Thu, 02 Jun 2011 15:18:02 -0600
> From: Rich Megginson <rmeggins(a)redhat.com>
> Subject: Re: [389-users] ds-admin script/package
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Message-ID: <4DE7FE0A.9020806(a)redhat.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 06/02/2011 03:14 PM, Danny Wall wrote:
> >
> > I may have used 389 base. I will try it later without the base. Thanks
> >
> 389-ds-base is in the base RHEL 6.1 OS. None of the other 389 packages
> such as 389-admin are available yet. I'm in the process of building
> them now for EPEL6. setup-ds.pl is provided by the 389-ds-base
> package. setup-ds-admin.pl is provided by the 389-admin package.
> > On Jun 2, 2011 5:11 PM, "solarflow99" <solarflow99(a)gmail.com
> > <mailto:solarflow99@gmail.com>> wrote:
> > > good, epel is the one to use. Did you use yum install 389-ds ? that
> will
> > > pull in the whole thing.
> > >
> > >
> > >
> > >
> > > 2011/6/2 Danny Wall <dwall72(a)gmail.com <mailto:dwall72@gmail.com>>
> > >
> > >> I first tried to the default rhel 6 repo then tried adding the epel
> > 6 repo.
> > >>
> > >>
> > >> Thanks
> > >> On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99(a)gmail.com
> > <mailto:solarflow99@gmail.com>> wrote:
> > >> > There are several RPM's involved, what repo and yum command did
> > you use?
> > >> >
> > >> >
> > >> > 2011/6/2 Danny Wall <dwall72(a)gmail.com <mailto:dwall72@gmail.com>>
> > >> >
> > >> >> I am setting up three RHEL 6 servers and am unable to find the
> > packages
> > >> or
> > >> >> scripts to install the admin console. In CentOS 5.5 and the 389
> > project,
> > >> the
> > >> >> packages are available, and I see references to
> > setup-ds-admin.pl <http://setup-ds-admin.pl> in
> > >> RHEL
> > >> >> 6 documentation and in searches. I have the dirsrv package
> > installed and
> > >> a
> > >> >> couple LDAP instances configured, but I have to use generic LDAP
> > >> browsers
> > >> >> for administration and can not configure password policies, etc.
> > that
> > >> appear
> > >> >> to require the admin console or web page.
> > >> >>
> > >> >> Can anyone point me to the missing link?
> > >> >>
> > >> >> Thanks
> > >> >>
> > >> >>
> > >> >> --
> > >> >> 389 users mailing list
> > >> >> 389-users(a)lists.fedoraproject.org
> > <mailto:389-users@lists.fedoraproject.org>
> > >> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> > >> >>
> > >>
> > >> --
> > >> 389 users mailing list
> > >> 389-users(a)lists.fedoraproject.org
> > <mailto:389-users@lists.fedoraproject.org>
> > >> https://admin.fedoraproject.org/mailman/listinfo/389-users
> > >>
> >
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/6...
>
> ------------------------------
>
> Message: 7
> Date: Fri, 03 Jun 2011 09:37:08 +0200
> From: Carsten Grzemba <grzemba(a)contac-dt.de>
> Subject: Re: [389-users] Windows Sync Agreement Help
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Message-ID: <fc54d5723506.4de8ab44(a)contac-dt.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> ----- Urspr?ngliche Nachricht -----
> Von: Rich Megginson <rmeggins(a)redhat.com>
> Datum: Mittwoch, 1. Juni 2011, 18:05
> Betreff: Re: [389-users] Windows Sync Agreement Help
> An: Albert Teh <teh.albert(a)gmail.com>
> Cc: "General discussion list for the 389 Directory server project." <
> 389-users(a)lists.fedoraproject.org>
>
>
>
>
>
>
>
>
>
> >
> On 06/01/2011 09:21 AM, Albert Teh wrote:
>
>
> The user: mailadm should have a full privilege from
> the AD because we are using this user for SUN's IDSYNC
> synchronizing/passwdsyc from the AD to the SUN's DS which is our
> current LDAP environment. We are trying to change SUN's Directory
> server to the Linux's 389-Directory server.
>
>
> No, its not true in general, Suns Idsync needs only a normal user, if you
> sync only from AD to DS. The user for Suns Idsync needs only additional
> privileges for see the 'deleted objects' container for syncing the object
> deletion. It do not use the dirsync ldap control where you need the
> Replication/Replicator rights
>
> Regards, Carsten
>
>
>
> >
> Ok.? I don't know how Sun's IDSYNC works - it is possible it doesn't
> use the DirSync control which requires Replicator privileges.? Can
> you confirm that
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" has
> Replication/Replicator rights in AD/Windows?
>
>
> >
> >
> ?
> >
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> has Replication/Replicator rights in AD/Windows?
>
> >
> >
> Thanks.
> >
> Albert
>
> >
>
> > On Wed, Jun 1, 2011 at 10:12 AM, Rich
> Megginson <rmeggins(a)redhat.com>
> wrote:
>
>
>
>
> > On 05/31/2011 06:30 PM, Albert Teh wrote:
>
>
> >
>
> > On Tue, May 31, 2011 at 2:58
> PM, Rich Megginson <rmeggins(a)redhat.com>
> wrote:
>
>
>
> > On 05/31/2011 12:49 PM, Albert Teh wrote:
>
> > Hi Rich,
>
> >
>
> > Sorry, What I understand doing the
> OneWay Sync from the AD to the DS
>
> >
> >
> Users in the Active Directory domain are
> synced if it is configured in the sync
> agreement by selecting the Sync
> New Windows Users option. All
> of the Windows users are copied to the
> Directory Server when synchronization is
> initiated and then new users are synced over
> when they are created.
>
> >
> >
> I do not need to do any AD to DS Group Sync
>
> >
> >
> and I am not doing any DS sync to the AD.
>
>
> >
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> -w - -D
>
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> -s base -b "" "objectclass=*"
>
> >
> >
> You should get the contents of the AD
>
> >
> >
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> -w - -D
>
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> -s sub -b
>
> "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> "objectclass=person"
>
> >
> >
> you should get the list of users
>
>
>
> >
>
> >
> >
> Thanks.
> >
> Al
>
> >
>
> > On Tue, May 31,
> 2011 at 1:40 PM, Rich Megginson <
> rmeggins(a)redhat.com>
> wrote:
>
>
>
> > On 05/31/2011 10:30 AM, Albert
> Teh wrote:
>
> >
> HI Rich,
>
> >
> >
> [root@algldap ~]#
> /usr/lib/mozldap/ldapsearch -x
> -w - -D cn="Directory Manager"
> -b
>
> "ou=People,dc=algonquincollege,dc=com"
> "(|(objectclass=ntuser)(objectclass=ntgroup))"
> >
> Enter bind password:
> >
> [root@algldap ~]#
>
> >
> >
> No Entry found !!!.
>
>
> >
> You have to tell directory server
> which entries you want to sync.
> >
> See
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-singl...
>
>
>
> >
> Thanks.
> >
> Albert
>
> >
>
> > On
> Tue, May 31, 2011 at 11:42
> AM, Rich Megginson <
> rmeggins(a)redhat.com>
> wrote:
>
>
>
> > On 05/30/2011
> 08:32 AM, Albert Teh
> wrote:
> > Hi
> Rich,
>
> >
>
> > I followed the
> Guide and still got
> the same result.
> Checked with? the AD
> administrator, the
> AD's user: mailadm
> has a full
> privilege.
>
>
> >
> /usr/bin/ldapsearch -x
> -w - -D cn="Directory
> Manager"-b
>
> "ou=People,dc=algonquincollege,dc=com"
> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>
> >
> >
> How many entries match
> that search?
>
>
>
> >
> >
> Thanks.
> >
> Albert
> >
> ? ?
> >
> Here is the
> Windows Sync
> Agreement info:
>
> >
> >
> [root@algldap
> slapd-algldap]#
>
> /usr/lib/mozldap/ldapsearch
> -w - -D
> cn="Directory
> Manager" -b
> cn=config
> cn=ADSync
> >
> Enter bind
> password:
> >
> version: 1
> >
> dn:
>
> cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
> tree,c
> >
> ?n=config
> >
> objectClass: top
> >
> objectClass:
>
> nsDSWindowsReplicationAgreement
> >
> description: AD
> Sync Agreement
> >
> cn: ADSync
> >
>
> nsds7WindowsReplicaSubtree:
>
> cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=co
> >
> ?m
> >
>
> nsds7DirectoryReplicaSubtree:
>
> ou=People,
>
> dc=algonquincollege,dc=com
> >
>
> nsds7NewWinUserSyncEnabled:
> on
> >
>
> nsds7NewWinGroupSyncEnabled:
>
> on
> >
> nsds7WindowsDomain:
>
> ottawa.ad.algonquincollege.com
> >
> nsDS5ReplicaRoot:
> dc=algonquincollege,dc=com
> >
> nsDS5ReplicaHost:
>
> wodcstage-1.ottawa.ad.algonquincollege.com
> >
> nsDS5ReplicaPort:
> 389
> >
> nsDS5ReplicaBindDN:
>
> cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc
> >
> ?=com
> >
>
> nsDS5ReplicaBindMethod:
> SIMPLE
> >
>
> nsDS5ReplicaCredentials:
>
> {DES}U68ooQM3C15xjJ/taDmy0A==
> >
>
> nsds5replicareapactive:
> 0
> >
>
> nsds5replicaLastUpdateStart:
>
> 20110530141648Z
> >
>
> nsds5replicaLastUpdateEnd:
>
> 20110530141648Z
> >
> nsds5replicaChangesSentSinceStartup:
> >
>
> nsds5replicaLastUpdateStatus:
>
> 0 Replica acquired
> successfully:
> Incremental upd
> >
> ?ate succeeded
> >
>
> nsds5replicaUpdateInProgress:
>
> FALSE
> >
>
> nsds5replicaLastInitStart:
>
> 20110530140648Z
> >
>
> nsds5replicaLastInitEnd:
>
> 20110530140648Z
> >
>
> nsds5replicaLastInitStatus:
> 0 Total update
> succeeded
> >
> [root@algldap
> slapd-algldap]#
>
> >
>
> >
>
> >
>
> > On
>
> Fri, May 27,
> 2011 at 10:57
> AM, Rich
> Megginson <
> rmeggins(a)redhat.com>
> wrote:
>
>
>
> > On
> 05/27/2011
> 04:22 AM,
> Albert Teh
> wrote:
> Hi
> Rich,
>
> >
> >
> I reinstalled
> 389-ds-base
> 1.2.8.3 from
> EPEL5 and
> added
> onewaysync set
> as fromWindows
> in the
> multimaster
> replication
> plugin. I
> still got the
> same result
> with no user
> created in the
> DS subtree.
>
>
> >
> Have you read
>
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-singl...
>
>
>
> >
> >
> Errors log:
>
> >
> >
>
> [27/May/2011:06:18:26
>
> -0400]
>
> NSMMReplicationPlugin
> - Beginning
> total update
> of replica
> "agmt="cn=ADSync"
> (wodcstage-1:389)".
> >
>
> [27/May/2011:06:18:26
>
> -0400]
>
> NSMMReplicationPlugin
> - Finished
> total update
> of replica
> "agmt="cn=ADSync"
>
> (wodcstage-1:389)".
>
> Sent 0
> entries.
>
> >
>
> >
> >
> Access log:
>
> >
> >
>
> [27/May/2011:06:18:29
>
> -0400] conn=1
> op=114 SRCH
>
> base="cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>
>
>
>
>
> tree,cn=config"
>
> scope=0
>
> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>
> attrs="nsds5replicaLastUpdateStart
>
>
>
>
> nsds5replicaLastUpdateEnd
>
>
>
> nsds5replicaChangesSentSinceStartup
>
>
>
> nsds5replicaLastUpdateStatus
>
>
>
> nsds5replicaUpdateInProgress
>
>
>
> nsds5replicaLastInitStart
>
>
>
> nsds5replicaLastInitEnd
>
>
> nsds5replicaLastInitStatus
> nsds5BeginReplicaRefresh"
> >
>
> [27/May/2011:06:18:29
>
> -0400] conn=1
> op=114 RESULT
> err=0 tag=101
> nentries=1
> etime=
>
> >
> >
> Thanks for
> your help.
>
> >
> >
> Albert
>
> >
>
> >
>
> >
>
> > On
>
>
> Thu, May 26,
> 2011 at 11:13
> AM, Rich
> Megginson <
> rmeggins(a)redhat.com>
> wrote:
>
>
>
> > On
> 05/26/2011
> 08:58 AM,
> Albert Teh
> wrote:
> Hi,
>
> >
> >
> We are setting
> up a new
> CENTOS-DS
> version 8.1.0.
> and CENTOS 5.5
> and attempt to
> synchronize
> with the
> existing 2003
> Windows AD
> server.
> >
> Performing?
> the full sync
> completed.
> There is no
> user created
> in the DS
> subtree.
>
> >
> >
> We would like
> to perform one
> way Sync:? AD
> ----> DS.
> Once it works,
> we will set up
> the password
> Sync from the
> AD to DS.
>
>
> >
> One way sync
> isn't
> supported with
> 8.1.0.? I
> suggest using
> 389-ds-base
> 1.2.8.3 from
> EPEL5 which
> does support
> one way sync.?
>
> http://directory.fedoraproject.org/wiki/One_Way_Active_Directory_Sync
>
>
> >
> >
> AD:??
>
> cn=Users,cn=location,dc=ad,dc=domain,dc=com
> >
> DS:??
>
> ou=Peoples,dc=domain,dc=com
>
> >
> >
> errors log:
>
> >
>
> >
> >
>
> [26/May/2011:10:20:34
>
>
> -0400]
>
> NSMMReplicationPlugin
> - Beginning
> total update
> of replica
> "agmt="cn=ADsync"
> (wodcstage-1:389)".
> >
>
> [26/May/2011:10:20:34
>
>
> -0400]
>
> NSMMReplicationPlugin
> - Finished
> total update
> of replica
> "agmt="cn=ADsync"
>
> (wodcstage-1:389)".
>
>
> Sent 0
> entries.
>
> >
> >
> access log:
>
> >
> >
>
> 26/May/2011:10:20:37
>
>
> -0400] conn=11
> op=819 SRCH
> base="cn=ADsync,
> cn=replica,
>
> cn=\22dc=algonquincollege,
> dc=com\22,
> cn=mapping
> tree,
> cn=config"
> scope=0
>
> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>
> attrs="nsds5replicaLastUpdateStart
>
>
>
>
>
> nsds5replicaLastUpdateEnd
>
>
>
>
> nsds5replicaChangesSentSinceStartup
>
>
>
>
> nsds5replicaLastUpdateStatus
>
>
>
>
> nsds5replicaUpdateInProgress
>
>
>
>
> nsds5replicaLastInitStart
>
>
>
> nsds5replicaLastInitEnd
> nsds5replicaLastInitStatus
> nsds5BeginReplicaRefresh"
> >
>
> [26/May/2011:10:20:37
>
>
> -0400] conn=11
> op=819 RESULT
> err=0 tag=101
> nentries=1
> etime=0
>
> >
>
> >
> >
> Thanks.
> >
> Albert
>
> >
>
> >
>
>
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
>
> >
>
> >
> >
> >
> --
> >
> Albert Teh
> >
> Email:
> Teh.Albert(a)Gmail.com
>
>
> >
>
>
>
>
>
>
> >
>
> >
> >
> >
> --
> >
> Albert Teh
> >
> Email:
> Teh.Albert(a)Gmail.com
>
>
> >
>
>
>
>
>
>
> >
>
> >
> >
> >
> --
> >
> Albert Teh
> >
> Email: Teh.Albert(a)Gmail.com
>
>
> >
>
>
>
>
>
>
> >
>
> >
> >
> >
> --
> >
> Albert Teh
> >
> Email: Teh.Albert(a)Gmail.com
>
>
> >
>
>
>
>
>
> >
>
> >
> >
> HI Rich,
>
> >
> >
> These two commands worked and got the result. I
> have been gone through? the Windows Sync agreement
> setup for many times. I could not figure out what
> went wrong.
> >
> Thanks a lot for your help again.
>
>
>
>
>
> >
> Are you sure that the user
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> has Replication/Replicator rights in AD/Windows?
>
>
>
>
>
> >
> >
> Albert
> >
> ?
>
>
> >
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> -w - -D "cn=mailadm,cn=Users,dc=[root@algldap ~]#
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> -w - -D
>
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> -s base -b ""
> "objectclass=*"??????????????????????????????????????????
> Enter bind password:
> >
> version: 1
> >
> dn:
> >
> currentTime: 20110601001342.0Z
> >
> subschemaSubentry:
>
> CN=Aggregate,CN=Schema,CN=Configuration,DC=ad,DC=algonquinc
> >
> ?ollege,DC=com
> >
> dsServiceName: CN=NTDS
> Settings,CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Sit
> >
> ?e-Name,CN=Sites,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> >
> namingContexts:
> CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> >
> namingContexts:
>
> CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> >
> namingContexts:
> DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> >
> defaultNamingContext:
> DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> >
> schemaNamingContext:
> CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=c
> >
> ?om
> >
> configurationNamingContext:
> CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> >
> rootDomainNamingContext:
> DC=ad,DC=algonquincollege,DC=com
> >
> supportedControl: 1.2.840.113556.1.4.319
> >
> supportedControl: 1.2.840.113556.1.4.801
> >
> supportedControl: 1.2.840.113556.1.4.473
> >
> supportedControl: 1.2.840.113556.1.4.528
> >
> supportedControl: 1.2.840.113556.1.4.417
> >
> supportedControl: 1.2.840.113556.1.4.619
> >
> supportedControl: 1.2.840.113556.1.4.841
> >
> supportedControl: 1.2.840.113556.1.4.529
> >
> supportedControl: 1.2.840.113556.1.4.805
> >
> supportedControl: 1.2.840.113556.1.4.521
> >
> supportedControl: 1.2.840.113556.1.4.970
> >
> supportedControl: 1.2.840.113556.1.4.1338
> >
> supportedControl: 1.2.840.113556.1.4.474
> >
> supportedControl: 1.2.840.113556.1.4.1339
> >
> supportedControl: 1.2.840.113556.1.4.1340
> >
> supportedControl: 1.2.840.113556.1.4.1413
> >
> supportedControl: 2.16.840.1.113730.3.4.9
> >
> supportedControl: 2.16.840.1.113730.3.4.10
> >
> supportedControl: 1.2.840.113556.1.4.1504
> >
> supportedControl: 1.2.840.113556.1.4.1852
> >
> supportedControl: 1.2.840.113556.1.4.802
> >
> supportedControl: 1.2.840.113556.1.4.1907
> >
> supportedControl: 1.2.840.113556.1.4.1948
> >
> supportedLDAPVersion: 3
> >
> supportedLDAPVersion: 2
> >
> supportedLDAPPolicies: MaxPoolThreads
> >
> supportedLDAPPolicies: MaxDatagramRecv
> >
> supportedLDAPPolicies: MaxReceiveBuffer
> >
> supportedLDAPPolicies: InitRecvTimeout
> >
> supportedLDAPPolicies: MaxConnections
> >
> supportedLDAPPolicies: MaxConnIdleTime
> >
> supportedLDAPPolicies: MaxPageSize
> >
> supportedLDAPPolicies: MaxQueryDuration
> >
> supportedLDAPPolicies: MaxTempTableSize
> >
> supportedLDAPPolicies: MaxResultSetSize
> >
> supportedLDAPPolicies: MaxNotificationPerConn
> >
> supportedLDAPPolicies: MaxValRange
> >
> highestCommittedUSN: 3103418
> >
> supportedSASLMechanisms: GSSAPI
> >
> supportedSASLMechanisms: GSS-SPNEGO
> >
> supportedSASLMechanisms: EXTERNAL
> >
> supportedSASLMechanisms: DIGEST-MD5
> >
> dnsHostName: WODCStage-1.ottawa.ad.algonquincollege.com
> >
> ldapServiceName: ad.algonquincollege.com:
> wodcstage-1$(a)OTTAWA.AD.ALGONQUINCOLLE
> >
> ?GE.COM
> >
> serverName:
>
> CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=C
> >
> ?onfiguration,DC=ad,DC=algonquincollege,DC=com
> >
> supportedCapabilities: 1.2.840.113556.1.4.800
> >
> supportedCapabilities: 1.2.840.113556.1.4.1670
> >
> supportedCapabilities: 1.2.840.113556.1.4.1791
> >
> isSynchronized: TRUE
> >
> isGlobalCatalogReady: TRUE
> >
> domainFunctionality: 2
> >
> forestFunctionality: 2
> >
> domainControllerFunctionality: 2
> >
> [root@algldap ~]#
>
> >
> >
> Partial out:
>
> >
> >
> [root@algldap ~]# /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> -w - -D
>
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> -s sub -b
> "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> "objectclass=person" | more
> >
> Enter bind password:
> >
> version: 1
> >
> dn:
>
> CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> >
> objectClass: top
> >
> objectClass: person
> >
> objectClass: organizationalPerson
> >
> objectClass: user
> >
> cn: isp-transfer
> >
> description: Transfer for Genesis Data to
> International Student Program share
> >
> givenName: isp-transfer
> >
> distinguishedName:
>
> CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincolleg
> >
> ?e,DC=com
> >
> instanceType: 4
> >
> whenCreated: 20040517155823.0Z
> >
> whenChanged: 20081016173006.0Z
> >
> displayName: isp-transfer
> >
> uSNCreated: 255422
> >
> memberOf:
>
> CN=NAS_Transfer_Genesis_ISP,OU=Groups,DC=ottawa,DC=ad,DC=algonquinco
> >
> ?llege,DC=com
> >
> uSNChanged: 255422
> >
> name: isp-transfer
> >
> objectGUID:: EaeRW3KiMUac6hzEs//X/g==
> >
> userAccountControl: 66048
> >
> badPwdCount: 0
> >
> codePage: 0
> >
> countryCode: 0
> >
> badPasswordTime: 0
> >
> lastLogoff: 0
> >
> lastLogon: 0
> >
> pwdLastSet: 127292831041031250
> >
> primaryGroupID: 513
> >
> objectSid:: AQUAAAAAAAUVAAAArhyVdhR1dBOOfkA4DN8BAA==
> >
> accountExpires: 9223372036854775807
> >
> logonCount: 0
> >
> sAMAccountName: isp-transfer
> >
> sAMAccountType: 805306368
> >
> userPrincipalName: isp-transfer(a)algonquincollege.com
> >
> lockoutTime: 0
> >
> objectCategory:
>
> CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege
> >
> ?,DC=com
> >
> dSCorePropagationData: 20110131155635.0Z
> >
> dSCorePropagationData: 20091227191115.0Z
> >
> dSCorePropagationData: 20090127144505.0Z
> >
> dSCorePropagationData: 20081201175842.0Z
> >
> dSCorePropagationData: 16010714223649.0Z
> >
> lastLogonTimestamp: 128686221598537375
>
> >
> >
> dn:
>
> CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> >
> objectClass: top
> >
> objectClass: person
> >
> objectClass: organizationalPerson
> >
> objectClass: user
> >
> cn: heatweb
> >
> sn: heatweb
> >
> description: Used to communicate between HEAT and IIS
> >
> distinguishedName:
>
> CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=
> >
> ?com
> >
> instanceType: 4
> >
> whenCreated: 20050218192725.0Z
> >
> whenChanged: 20081016172611.0Z
> >
> displayName: heatweb
> >
> uSNCreated: 89976
> >
> memberOf: CN=Heat
> Users,OU=Groups,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> >
> uSNChanged: 89976
> >
> name: heatweb
> >
> objectGUID:: 07KJaAgkGUapXbQN7VprrQ==
> >
> userAccountControl: 66048
> >
> badPwdCount: 0
> >
> codePage: 0
> >
> countryCode: 0
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> --
> >
> Albert Teh
> >
> Email: Teh.Albert(a)Gmail.com
>
>
> >
>
>
>
>
>
>
> >
>
> >
> >
> >
> --
> >
> Albert Teh
> >
> Email: Teh.Albert(a)Gmail.com
>
>
> >
>
>
>
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: grzemba.vcf
> Type: text/x-vcard
> Size: 233 bytes
> Desc: Card for Carsten Grzemba <grzemba(a)contac-dt.de>
> Url :
> http://lists.fedoraproject.org/pipermail/389-users/attachments/20110603/0...
>
> ------------------------------
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> End of 389-users Digest, Vol 73, Issue 7
> ****************************************
>
--
Albert Teh
Email: Teh.Albert(a)Gmail.com
13 years
- 3
- 3
Re: [389-users] Windows Sync Agreement Help
by Albert Teh
On Tue, May 31, 2011 at 2:58 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
> On 05/31/2011 12:49 PM, Albert Teh wrote:
>
> Hi Rich,
>
> Sorry, What I understand doing the OneWay Sync from the AD to the DS
>
> Users in the Active Directory domain are synced if it is configured in the
> sync agreement by selecting the *Sync New Windows Users* option. All of
> the Windows users are copied to the Directory Server when synchronization is
> initiated and then new users are synced over when they are created.
>
> I do not need to do any AD to DS Group Sync
>
> and I am not doing any DS sync to the AD.
>
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com -w - -D
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" -s base -b
> "" "objectclass=*"
>
> You should get the contents of the AD
>
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com -w - -D
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" -s sub -b
> "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" "objectclass=person"
>
> you should get the list of users
>
>
>
> Thanks.
> Al
>
> On Tue, May 31, 2011 at 1:40 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>
>> On 05/31/2011 10:30 AM, Albert Teh wrote:
>>
>>
>> HI Rich,
>>
>> [root@algldap ~]# /usr/lib/mozldap/ldapsearch -x -w - -D cn="Directory
>> Manager" -b "ou=People,dc=algonquincollege,dc=com"
>> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>> Enter bind password:
>> [root@algldap ~]#
>>
>> No Entry found !!!.
>>
>> You have to tell directory server which entries you want to sync.
>> See
>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-singl...
>>
>>
>> Thanks.
>> Albert
>>
>> On Tue, May 31, 2011 at 11:42 AM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>
>>> On 05/30/2011 08:32 AM, Albert Teh wrote:
>>>
>>> Hi Rich,
>>>
>>> I followed the Guide and still got the same result. Checked with the AD
>>> administrator, the AD's user: mailadm has a full privilege.
>>>
>>> /usr/bin/ldapsearch -x -w - -D cn="Directory Manager"-b
>>> "ou=People,dc=algonquincollege,dc=com"
>>> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>>>
>>> How many entries match that search?
>>>
>>>
>>> Thanks.
>>> Albert
>>>
>>> Here is the Windows Sync Agreement info:
>>>
>>> [root@algldap slapd-algldap]# /usr/lib/mozldap/ldapsearch -w - -D
>>> cn="Directory Manager" -b cn=config cn=ADSync
>>> Enter bind password:
>>> version: 1
>>> dn: cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>>> tree,c
>>> n=config
>>> objectClass: top
>>> objectClass: nsDSWindowsReplicationAgreement
>>> description: AD Sync Agreement
>>> cn: ADSync
>>> nsds7WindowsReplicaSubtree:
>>> cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=co
>>> m
>>> nsds7DirectoryReplicaSubtree: ou=People, dc=algonquincollege,dc=com
>>> nsds7NewWinUserSyncEnabled: on
>>> nsds7NewWinGroupSyncEnabled: on
>>> nsds7WindowsDomain: ottawa.ad.algonquincollege.com
>>> nsDS5ReplicaRoot: dc=algonquincollege,dc=com
>>> nsDS5ReplicaHost: wodcstage-1.ottawa.ad.algonquincollege.com
>>> nsDS5ReplicaPort: 389
>>> nsDS5ReplicaBindDN:
>>> cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc
>>> =com
>>> nsDS5ReplicaBindMethod: SIMPLE
>>> nsDS5ReplicaCredentials: {DES}U68ooQM3C15xjJ/taDmy0A==
>>> nsds5replicareapactive: 0
>>> nsds5replicaLastUpdateStart: 20110530141648Z
>>> nsds5replicaLastUpdateEnd: 20110530141648Z
>>> nsds5replicaChangesSentSinceStartup:
>>> nsds5replicaLastUpdateStatus: 0 Replica acquired successfully:
>>> Incremental upd
>>> ate succeeded
>>> nsds5replicaUpdateInProgress: FALSE
>>> nsds5replicaLastInitStart: 20110530140648Z
>>> nsds5replicaLastInitEnd: 20110530140648Z
>>> nsds5replicaLastInitStatus: 0 Total update succeeded
>>> [root@algldap slapd-algldap]#
>>>
>>>
>>>
>>> On Fri, May 27, 2011 at 10:57 AM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>>
>>>> On 05/27/2011 04:22 AM, Albert Teh wrote:
>>>>
>>>> Hi Rich,
>>>>
>>>> I reinstalled 389-ds-base 1.2.8.3 from EPEL5 and added onewaysync set as
>>>> fromWindows in the multimaster replication plugin. I still got the same
>>>> result with no user created in the DS subtree.
>>>>
>>>> Have you read
>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-singl...
>>>>
>>>>
>>>> Errors log:
>>>>
>>>> [27/May/2011:06:18:26 -0400] NSMMReplicationPlugin - Beginning total
>>>> update of replica "agmt="cn=ADSync" (wodcstage-1:389)".
>>>> [27/May/2011:06:18:26 -0400] NSMMReplicationPlugin - Finished total
>>>> update of replica "agmt="cn=ADSync" (wodcstage-1:389)". Sent 0 entries.
>>>>
>>>>
>>>> Access log:
>>>>
>>>> [27/May/2011:06:18:29 -0400] conn=1 op=114 SRCH
>>>> base="cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>>>> tree,cn=config" scope=0
>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>> attrs="nsds5replicaLastUpdateStart nsds5replicaLastUpdateEnd
>>>> nsds5replicaChangesSentSinceStartup nsds5replicaLastUpdateStatus
>>>> nsds5replicaUpdateInProgress nsds5replicaLastInitStart
>>>> nsds5replicaLastInitEnd nsds5replicaLastInitStatus nsds5BeginReplicaRefresh"
>>>> [27/May/2011:06:18:29 -0400] conn=1 op=114 RESULT err=0 tag=101
>>>> nentries=1 etime=
>>>>
>>>> Thanks for your help.
>>>>
>>>> Albert
>>>>
>>>>
>>>>
>>>> On Thu, May 26, 2011 at 11:13 AM, Rich Megginson <rmeggins(a)redhat.com>wrote:
>>>>
>>>>> On 05/26/2011 08:58 AM, Albert Teh wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> We are setting up a new CENTOS-DS version 8.1.0. and CENTOS 5.5 and
>>>>> attempt to synchronize with the existing 2003 Windows AD server.
>>>>> Performing the full sync completed. There is no user created in the DS
>>>>> subtree.
>>>>>
>>>>> We would like to perform one way Sync: AD ----> DS. Once it works, we
>>>>> will set up the password Sync from the AD to DS.
>>>>>
>>>>> One way sync isn't supported with 8.1.0. I suggest using 389-ds-base
>>>>> 1.2.8.3 from EPEL5 which does support one way sync.
>>>>> http://directory.fedoraproject.org/wiki/One_Way_Active_Directory_Sync
>>>>>
>>>>>
>>>>> AD: cn=Users,cn=location,dc=ad,dc=domain,dc=com
>>>>> DS: ou=Peoples,dc=domain,dc=com
>>>>>
>>>>> errors log:
>>>>>
>>>>>
>>>>> [26/May/2011:10:20:34 -0400] NSMMReplicationPlugin - Beginning total
>>>>> update of replica "agmt="cn=ADsync" (wodcstage-1:389)".
>>>>> [26/May/2011:10:20:34 -0400] NSMMReplicationPlugin - Finished total
>>>>> update of replica "agmt="cn=ADsync" (wodcstage-1:389)". Sent 0 entries.
>>>>>
>>>>> access log:
>>>>>
>>>>> 26/May/2011:10:20:37 -0400] conn=11 op=819 SRCH base="cn=ADsync,
>>>>> cn=replica, cn=\22dc=algonquincollege, dc=com\22, cn=mapping tree,
>>>>> cn=config" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>> attrs="nsds5replicaLastUpdateStart nsds5replicaLastUpdateEnd
>>>>> nsds5replicaChangesSentSinceStartup nsds5replicaLastUpdateStatus
>>>>> nsds5replicaUpdateInProgress nsds5replicaLastInitStart
>>>>> nsds5replicaLastInitEnd nsds5replicaLastInitStatus nsds5BeginReplicaRefresh"
>>>>> [26/May/2011:10:20:37 -0400] conn=11 op=819 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>>
>>>>>
>>>>> Thanks.
>>>>> Albert
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Albert Teh
>>>> Email: Teh.Albert(a)Gmail.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Albert Teh
>>> Email: Teh.Albert(a)Gmail.com
>>>
>>>
>>>
>>
>>
>> --
>> Albert Teh
>> Email: Teh.Albert(a)Gmail.com
>>
>>
>>
>
>
> --
> Albert Teh
> Email: Teh.Albert(a)Gmail.com
>
>
>
HI Rich,
These two commands worked and got the result. I have been gone through the
Windows Sync agreement setup for many times. I could not figure out what
went wrong.
Thanks a lot for your help again.
Albert
/usr/lib/mozldap/ldapsearch -x -h
wodcstage-1.ottawa.ad.algonquincollege.com-w - -D
"cn=mailadm,cn=Users,dc=[root@algldap~]# /usr/lib/mozldap/ldapsearch
-x -h
wodcstage-1.ottawa.ad.algonquincollege.com -w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" -s base -b
"" "objectclass=*" Enter bind
password:
version: 1
dn:
currentTime: 20110601001342.0Z
subschemaSubentry:
CN=Aggregate,CN=Schema,CN=Configuration,DC=ad,DC=algonquinc
ollege,DC=com
dsServiceName: CN=NTDS
Settings,CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Sit
e-Name,CN=Sites,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
namingContexts: CN=Configuration,DC=ad,DC=algonquincollege,DC=com
namingContexts: CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
namingContexts: DC=ottawa,DC=ad,DC=algonquincollege,DC=com
defaultNamingContext: DC=ottawa,DC=ad,DC=algonquincollege,DC=com
schemaNamingContext:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=c
om
configurationNamingContext:
CN=Configuration,DC=ad,DC=algonquincollege,DC=com
rootDomainNamingContext: DC=ad,DC=algonquincollege,DC=com
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.840.113556.1.4.801
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 1.2.840.113556.1.4.528
supportedControl: 1.2.840.113556.1.4.417
supportedControl: 1.2.840.113556.1.4.619
supportedControl: 1.2.840.113556.1.4.841
supportedControl: 1.2.840.113556.1.4.529
supportedControl: 1.2.840.113556.1.4.805
supportedControl: 1.2.840.113556.1.4.521
supportedControl: 1.2.840.113556.1.4.970
supportedControl: 1.2.840.113556.1.4.1338
supportedControl: 1.2.840.113556.1.4.474
supportedControl: 1.2.840.113556.1.4.1339
supportedControl: 1.2.840.113556.1.4.1340
supportedControl: 1.2.840.113556.1.4.1413
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.10
supportedControl: 1.2.840.113556.1.4.1504
supportedControl: 1.2.840.113556.1.4.1852
supportedControl: 1.2.840.113556.1.4.802
supportedControl: 1.2.840.113556.1.4.1907
supportedControl: 1.2.840.113556.1.4.1948
supportedLDAPVersion: 3
supportedLDAPVersion: 2
supportedLDAPPolicies: MaxPoolThreads
supportedLDAPPolicies: MaxDatagramRecv
supportedLDAPPolicies: MaxReceiveBuffer
supportedLDAPPolicies: InitRecvTimeout
supportedLDAPPolicies: MaxConnections
supportedLDAPPolicies: MaxConnIdleTime
supportedLDAPPolicies: MaxPageSize
supportedLDAPPolicies: MaxQueryDuration
supportedLDAPPolicies: MaxTempTableSize
supportedLDAPPolicies: MaxResultSetSize
supportedLDAPPolicies: MaxNotificationPerConn
supportedLDAPPolicies: MaxValRange
highestCommittedUSN: 3103418
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
dnsHostName: WODCStage-1.ottawa.ad.algonquincollege.com
ldapServiceName: ad.algonquincollege.com:
wodcstage-1$(a)OTTAWA.AD.ALGONQUINCOLLE
GE.COM
serverName:
CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=C
onfiguration,DC=ad,DC=algonquincollege,DC=com
supportedCapabilities: 1.2.840.113556.1.4.800
supportedCapabilities: 1.2.840.113556.1.4.1670
supportedCapabilities: 1.2.840.113556.1.4.1791
isSynchronized: TRUE
isGlobalCatalogReady: TRUE
domainFunctionality: 2
forestFunctionality: 2
domainControllerFunctionality: 2
[root@algldap ~]#
Partial out:
[root@algldap ~]# /usr/lib/mozldap/ldapsearch -x -h
wodcstage-1.ottawa.ad.algonquincollege.com -w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" -s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" "objectclass=person" |
more
Enter bind password:
version: 1
dn: CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: isp-transfer
description: Transfer for Genesis Data to International Student Program
share
givenName: isp-transfer
distinguishedName:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincolleg
e,DC=com
instanceType: 4
whenCreated: 20040517155823.0Z
whenChanged: 20081016173006.0Z
displayName: isp-transfer
uSNCreated: 255422
memberOf:
CN=NAS_Transfer_Genesis_ISP,OU=Groups,DC=ottawa,DC=ad,DC=algonquinco
llege,DC=com
uSNChanged: 255422
name: isp-transfer
objectGUID:: EaeRW3KiMUac6hzEs//X/g==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 127292831041031250
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAArhyVdhR1dBOOfkA4DN8BAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: isp-transfer
sAMAccountType: 805306368
userPrincipalName: isp-transfer(a)algonquincollege.com
lockoutTime: 0
objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege
,DC=com
dSCorePropagationData: 20110131155635.0Z
dSCorePropagationData: 20091227191115.0Z
dSCorePropagationData: 20090127144505.0Z
dSCorePropagationData: 20081201175842.0Z
dSCorePropagationData: 16010714223649.0Z
lastLogonTimestamp: 128686221598537375
dn: CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: heatweb
sn: heatweb
description: Used to communicate between HEAT and IIS
distinguishedName:
CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=
com
instanceType: 4
whenCreated: 20050218192725.0Z
whenChanged: 20081016172611.0Z
displayName: heatweb
uSNCreated: 89976
memberOf: CN=Heat Users,OU=Groups,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
uSNChanged: 89976
name: heatweb
objectGUID:: 07KJaAgkGUapXbQN7VprrQ==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
--
Albert Teh
Email: Teh.Albert(a)Gmail.com
13 years
- 4
- 7
ds-admin script/package
by Danny Wall
I am setting up three RHEL 6 servers and am unable to find the packages or
scripts to install the admin console. In CentOS 5.5 and the 389 project, the
packages are available, and I see references to setup-ds-admin.pl in RHEL 6
documentation and in searches. I have the dirsrv package installed and a
couple LDAP instances configured, but I have to use generic LDAP browsers
for administration and can not configure password policies, etc. that appear
to require the admin console or web page.
Can anyone point me to the missing link?
Thanks
13 years
- 3
- 5