date:20160517

[389-users] Re: Auditing Tool for Directory Server

2016-05-17 Thread Dhiraj Deshpande

Thanks William, that helped.

On Wed, May 18, 2016 at 8:40 AM, William Brown  wrote:

> On Wed, 2016-05-18 at 08:24 +0530, Dhiraj Deshpande wrote:
> > For e.g x user's lastlogon information.
> >
> > ntUserLastLogon: 131064093305375272
> >
> > Need to convert it into IST.
> >
>
>
> http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontime
> stamp-and-lastlogondate.aspx
>
> This should help you. That value is winsynced from AD as I understand it,
> so you can look up what the syntax of the AD lastLogon
> value is.
>
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
>
> --
> 389-users mailing list
> 389-users@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
>


-- 


Thanks & Regards
Dhiraj S. Deshpande
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Auditing Tool for Directory Server

2016-05-17 Thread William Brown

On Wed, 2016-05-18 at 08:24 +0530, Dhiraj Deshpande wrote:
> For e.g x user's lastlogon information.
> 
> ntUserLastLogon: 131064093305375272
> 
> Need to convert it into IST.
> 

http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontime
stamp-and-lastlogondate.aspx

This should help you. That value is winsynced from AD as I understand it, so 
you can look up what the syntax of the AD lastLogon
value is. 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane



signature.asc
Description: This is a digitally signed message part
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Auditing Tool for Directory Server

2016-05-17 Thread Dhiraj Deshpande

For e.g x user's lastlogon information.

ntUserLastLogon: 131064093305375272

Need to convert it into IST.

On Tue, May 17, 2016 at 4:13 AM, William Brown  wrote:

> On Mon, 2016-05-16 at 10:00 +0530, Dhiraj Deshpande wrote:
> > Hi William,
> >
> > I tried querying that but not able to convert the timestamp format into
> > IST. Can you please post one example query for one user's last login time
> > to be converted.
> >
>
>
> Can you post what attribute you are looking at, that way I know what the
> correct time format is.
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
>
> --
> 389-users mailing list
> 389-users@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
>


-- 


Thanks & Regards
Dhiraj S. Deshpande
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Noriko Hosoi


Thanks a lot, Alberto!

I've opened a ticket:
https://fedorahosted.org/389/ticket/48841

On 05/17/2016 12:27 PM, Alberto Viana wrote:

Noriko,

/I have one question.  In your first email, you wrote this, in which 
the problem is in 2012R2, but not in 2008R2./


*Sorry, I don't have any 2008 r2 in my lab... I just tested with 2012 
r2 and it failed. *

*
*
*Here's my scenarios*
*
*
*My lab environment:*
*389-ds-base 1.3.4.8 + win 2012 r2*
*
*
*OU just in 389 side with users: Full sync failed, log error:*
*
*
*
[17/May/2016:14:19:44 -0300] - Attempting to add entry cn=mais um 
teste,ou=teste,ou=RNP,dc=homolog,dc=rnp to AD for local entry 
uid=teste.teste,ou=teste,ou=RNP,dc=homolog,dc=rnp
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result code 32 
(208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, 
best match of:   'OU=RNP,DC=homolog,DC=rnp' ) for add operation
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): 
windows_process_total_add: Cannot replay add operation.
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the 
connection
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed 
to obtain data to send to the consumer; LDAP error - 1

[17/May/2016:14:19:44 -0300] - Calling dirsync search request plugin
[17/May/2016:14:19:44 -0300] - Sending dirsync search request
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Cancelling linger on the 
connection
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Disconnected from the 
consumer
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync - 
windows_inc_runs: cancelled dirsync: 7fa660001d60, rval: 1


*
*
*
*OU just in AD side with users: Full sync ok*
*
*

*My production environment:*
*389-ds-base 1.3.2.19 + win 2008 r2 *
*
*
*OU just in 389 side with users: Full sync ok*
*OU just in AD side with users: Full sync ok*
*
*
*
*
*If you need any other info, please let me know.*
*
*
*
*

On Tue, May 17, 2016 at 2:54 PM, Noriko Hosoi > wrote:


Thank you for your input, Alberto.

On 05/17/2016 07:38 AM, Alberto Viana wrote:

Rich,

I'm aware of that, what I'm trying to say is: Is the expected
behavior to sync do not complete or stop because of one or more
OUs does not exists in one of the sides (389 or AD)? Is not
suppose to just generate some error and must go on?

I think so, too.

I have one question.  In your first email, you wrote this, in
which the problem is in 2012R2, but not in 2008R2.
> I'm trying to setup a new scenario with 389 and AD 2012 R2 (So
far I'm using with AD 2008 R2 and everything works fine).

Did you have a chance to run "full sync" against 2008R2, as well? 
Or just against 2012R2 and it failed?


There should not be a difference there, IMO...

Thanks,
--noriko


Thanx

On Tue, May 17, 2016 at 11:26 AM, Rich Megginson
> wrote:

On 05/17/2016 08:01 AM, Alberto Viana wrote:

Noriko,

Just to let you know, after I replicated/created the exactly
same OU structure on both side, the replication seems to
works fine. I'm still not sure that is the expected behavior:


Yes, it is.  Winsync does _not_ sync the OU structure - you
have to set that up manually so that the OU structure in AD
matches the OU structure in 389.




[17/May/2016:10:56:53 -0300] - windows_conn_connect :
detected Win2k3 or later peer
[17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No
linger to cancel on the connection
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time:
gen state before 573b22010001:1463493115:0:6
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time:
gen state after 573b232c:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows
sync - windows_acquire_replica returned success (101)
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
ready_to_acquire_replica -> sending_updates
[17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state
before 573b232c0001:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin -
changelog program - _cl5GetDBFile: found DB object 1b9d570
for database

[389-users] x-forwarded-for

2016-05-17 Thread Robert Viduya

We run a cluster of directory servers (4 masters, 2 hubs, 14 slaves) behind a set of F5 Bigip load balancers.  Our Bigip admins recently decided to switch the boxes to "one-armed" mode and that services would have to use X-Forwarded-For headers or equivalent to get the actual client IP address.  Obviously, LDAP has no equivalent.So, I've hacked something together and I'm posting it looking for feedback.  If the stuff is actually usable for other folks, that's good too.On the load balancer side, the code is specifically for the F5 Bigips.  But if other load balancers have similar abilities to trigger on events and can insert binary data into the datastream, it should be adaptable.Essentially what I've done is defined a new LDAP Extended Operation with a payload that's a string containing the source IP address of the incoming connection.  The load balancer sends this LDAP operation as soon as it opens a connection to the LDAP server, before any other traffic gets sent.  On the directory server side, I've written an Extended Operation plugin that then logs the string.  All we need is logging, so that's good enough for us.  There's room for improvement there though, like making the address available for IP based ACls (which we don't use).In order to insert an LDAP operation into the stream, the code on the load balancer needs to choose an LDAP message-id that hopefully the real client isn't going to use.  Going on the assumption that the client will start at 0 and increment up, I had the code insert a message-id of 0x7000.  I initially thought I'd have to have the code on the load balancer look for the response message and throw it away so the client doesn't see it, but I've found that the clients just seem to ignore it with no ill effects, so I haven't bothered filtering the response out.  The less the code on the load balancer does, the better.There's a possibility that the client could send it's own xff extended operation, but since the load balancer always sends first, we can just ignore any subsequent log entries.On the directory server plugin side, I needed to be able to log this to the access log, not to the error log.  The slapi_log_access function isn't declared in the plugin header file, so I had to declare it manually.Here's what our log entries look like now, for both 636 (SSL) and 389 (cleartext before starttls):[17/May/2016:15:34:22 -0400] conn=230843 fd=156 slot=156 SSL connection from 130.207.167.12 to 130.207.183.16[17/May/2016:15:34:22 -0400] conn=230843 op=0 EXT oid="1.3.6.1.4.1.636.2.11.11.1" name="forwarded-for extended op"[17/May/2016:15:34:22 -0400] conn=230843 op=0 forwarded for 130.207.167.12[17/May/2016:15:34:22 -0400] conn=230843 op=0 RESULT err=0 tag=120 nentries=0 etime=0[17/May/2016:15:34:22 -0400] conn=230844 fd=156 slot=156 connection from 130.207.167.12 to 130.207.183.16[17/May/2016:15:34:22 -0400] conn=230844 op=0 EXT oid="1.3.6.1.4.1.636.2.11.11.1" name="forwarded-for extended op"[17/May/2016:15:34:22 -0400] conn=230844 op=0 forwarded for 130.207.167.12[17/May/2016:15:34:22 -0400] conn=230844 op=0 RESULT err=0 tag=120 nentries=0 etime=0We haven't switched our Bigips yet, so the "connection from" line still shows the actual client IP address.F5 Bigip code fragments are called "irules" and are written in TCL.  The tar file below contains two different irule files, one for cleartext streams and one for SSL streams.  By SSL streams, I mean where SSL connections from the client are terminated at the load balancer and then re-SSLed to the ldap server.  Sorry, I'm not writing the other kind.

ldapxff.tar
Description: Unix tar archive
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Alberto Viana

Noriko,

*I have one question.  In your first email, you wrote this, in which the
problem is in 2012R2, but not in 2008R2.*

*Sorry, I don't have any 2008 r2 in my lab... I just tested with 2012 r2
and it failed. *

*Here's my scenarios*

*My lab environment:*
*389-ds-base 1.3.4.8 + win 2012 r2*

*OU just in 389 side with users: Full sync failed, log error:*


*[17/May/2016:14:19:44 -0300] - Attempting to add entry cn=mais um
teste,ou=teste,ou=RNP,dc=homolog,dc=rnp to AD for local entry
uid=teste.teste,ou=teste,ou=RNP,dc=homolog,dc=rnp[17/May/2016:14:19:44
-0300] NSMMReplicationPlugin - windows sync - agmt="cn=AD - DF-GTI-DC01"
(gti-df-dc01:636): Received result code 32 (208D: NameErr:
DSID-03100238, problem 2001 (NO_OBJECT), data 0, best match of:
'OU=RNP,DC=homolog,DC=rnp' ) for add operation[17/May/2016:14:19:44 -0300]
NSMMReplicationPlugin - windows sync - agmt="cn=AD - DF-GTI-DC01"
(gti-df-dc01:636): windows_process_total_add: Cannot replay add
operation.[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the
connection[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed to
obtain data to send to the consumer; LDAP error - 1[17/May/2016:14:19:44
-0300] - Calling dirsync search request plugin[17/May/2016:14:19:44 -0300]
- Sending dirsync search request[17/May/2016:14:19:45 -0300]
NSMMReplicationPlugin - windows sync - agmt="cn=AD - DF-GTI-DC01"
(gti-df-dc01:636): Cancelling linger on the connection[17/May/2016:14:19:45
-0300] NSMMReplicationPlugin - windows sync - agmt="cn=AD - DF-GTI-DC01"
(gti-df-dc01:636): Disconnected from the consumer[17/May/2016:14:19:45
-0300] NSMMReplicationPlugin - windows sync - windows_inc_runs: cancelled
dirsync: 7fa660001d60, rval: 1*

*OU just in AD side with users: Full sync ok*


*My production environment:*
*389-ds-base 1.3.2.19 + win 2008 r2 *

*OU just in 389 side with users: Full sync ok*
*OU just in AD side with users: Full sync ok*


*If you need any other info, please let me know.*



On Tue, May 17, 2016 at 2:54 PM, Noriko Hosoi  wrote:

> Thank you for your input, Alberto.
>
> On 05/17/2016 07:38 AM, Alberto Viana wrote:
>
> Rich,
>
> I'm aware of that, what I'm trying to say is: Is the expected behavior to
> sync do not complete or stop because of one or more OUs does not exists in
> one of the sides (389 or AD)? Is not suppose to just generate some error
> and must go on?
>
> I think so, too.
>
> I have one question.  In your first email, you wrote this, in which the
> problem is in 2012R2, but not in 2008R2.
> > I'm trying to setup a new scenario with 389 and AD 2012 R2 (So far I'm
> using with AD 2008 R2 and everything works fine).
>
> Did you have a chance to run "full sync" against 2008R2, as well?  Or just
> against 2012R2 and it failed?
>
> There should not be a difference there, IMO...
>
> Thanks,
> --noriko
>
> Thanx
>
> On Tue, May 17, 2016 at 11:26 AM, Rich Megginson 
> wrote:
>
>> On 05/17/2016 08:01 AM, Alberto Viana wrote:
>>
>> Noriko,
>>
>> Just to let you know, after I replicated/created the exactly same OU
>> structure on both side, the replication seems to works fine. I'm still not
>> sure that is the expected behavior:
>>
>>
>> Yes, it is.  Winsync does _not_ sync the OU structure - you have to set
>> that up manually so that the OU structure in AD matches the OU structure in
>> 389.
>>
>>
>>
>> [17/May/2016:10:56:53 -0300] - windows_conn_connect : detected Win2k3 or
>> later peer
>> [17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows sync -
>> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No linger to cancel on the
>> connection
>> [17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state
>> before 573b22010001:1463493115:0:6
>> [17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state after
>> 573b232c:1463493414:0:6
>> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync -
>> windows_acquire_replica returned success (101)
>> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync -
>> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
>> ready_to_acquire_replica -> sending_updates
>> [17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state before
>> 573b232c0001:1463493414:0:6
>> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - changelog program -
>> _cl5GetDBFile: found DB object 1b9d570 for database
>> /opt/dirsrv/var/lib/dirsrv/slapd-RNP/changelogdb/169ce382-1b9011e6-91ddc5b4-dc63c95a_55c88d9900c8.db
>>
>>
>> On Tue, May 17, 2016 at 10:08 AM, Alberto Viana < 
>> alberto...@gmail.com> wrote:
>>
>>> Noriko,
>>>
>>> *Did you use the same version of 389-ds-base against AD on 2008 R2 and
>>> 2012 R2?*
>>> *389-Directory/1.3.4.8  B2016.063.1654*
>>> *Please share the output frpm this command line "rpm -q 389-ds-base"?*
>>>

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Noriko Hosoi

Thank you for your input, Alberto.

On 05/17/2016 07:38 AM, Alberto Viana wrote:

Rich,

I'm aware of that, what I'm trying to say is: Is the expected behavior 
to sync do not complete or stop because of one or more OUs does not 
exists in one of the sides (389 or AD)? Is not suppose to just 
generate some error and must go on?

I think so, too.

I have one question.  In your first email, you wrote this, in which the 
problem is in 2012R2, but not in 2008R2.
> I'm trying to setup a new scenario with 389 and AD 2012 R2 (So far 
I'm using with AD 2008 R2 and everything works fine).

Did you have a chance to run "full sync" against 2008R2, as well? Or 
just against 2012R2 and it failed?

There should not be a difference there, IMO...

Thanks,
--noriko

Thanx

On Tue, May 17, 2016 at 11:26 AM, Rich Megginson > wrote:

On 05/17/2016 08:01 AM, Alberto Viana wrote:

Noriko,

Just to let you know, after I replicated/created the exactly same
OU structure on both side, the replication seems to works fine.
I'm still not sure that is the expected behavior:

Yes, it is.  Winsync does _not_ sync the OU structure - you have
to set that up manually so that the OU structure in AD matches the
OU structure in 389.

[17/May/2016:10:56:53 -0300] - windows_conn_connect : detected
Win2k3 or later peer
[17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No linger to
cancel on the connection
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen
state before 573b22010001:1463493115:0:6
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen
state after 573b232c:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync
- windows_acquire_replica returned success (101)
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
ready_to_acquire_replica -> sending_updates
[17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state
before 573b232c0001:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - changelog
program - _cl5GetDBFile: found DB object 1b9d570 for database

/opt/dirsrv/var/lib/dirsrv/slapd-RNP/changelogdb/169ce382-1b9011e6-91ddc5b4-dc63c95a_55c88d9900c8.db

On Tue, May 17, 2016 at 10:08 AM, Alberto Viana
> wrote:

Noriko,
/
/
/Did you use the same version of 389-ds-base against AD on
2008 R2 and 2012 R2?/
/389-Directory/1.3.4.8  B2016.063.1654/
/Please share the output frpm this command line "rpm -q
389-ds-base"?/

*I compiled 389 manually once the package in apt repo is too
old for me (I'm using ubuntu 14.04 LTS). What specific info
do you need?*
*ds-base is 1.3.4.8*

/Does this error message follow some other detailed error
messages?  Such as .../
/YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP error
(ERROR_CODE) ERROR_MESSAGE/
/or /
/YOUR_AGREEMENT: Received error [%s] when attempting to %s
entry [%s]: Please correct the attribute specified in the
error message. Refer to the Windows Active Directory docs for
more information./
/If not, could you enable the replication log level and share
the error log with us?/

*After enable replication log level:*
*[17/May/2016:09:13:18 -0300] - Attempting to add entry
cn=Benedito
Maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp
to AD for local entry

uid=benedito.maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received
result code 32 (208D: NameErr: DSID-03100238, problem
2001 (NO_OBJECT), data 0, best match of:
'OU=POPS,OU=EXTERNOS,OU=RNP,DC=homolog,DC=rnp' ) for add
operation *
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636):
windows_process_total_add: Cannot replay add operation.*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636):
Beginning linger on the connection*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636):
windows_tot_run: failed to obtain data to send to the
consumer; LDAP error - 1*
*
*
*Once I do not have the same OU structure on both side (for
testing purposes), I created

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Alberto Viana

Rich,

I'm aware of that, what I'm trying to say is: Is the expected behavior to
sync do not complete or stop because of one or more OUs does not exists in
one of the sides (389 or AD)? Is not suppose to just generate some error
and must go on?

Thanx

On Tue, May 17, 2016 at 11:26 AM, Rich Megginson 
wrote:

> On 05/17/2016 08:01 AM, Alberto Viana wrote:
>
> Noriko,
>
> Just to let you know, after I replicated/created the exactly same OU
> structure on both side, the replication seems to works fine. I'm still not
> sure that is the expected behavior:
>
>
> Yes, it is.  Winsync does _not_ sync the OU structure - you have to set
> that up manually so that the OU structure in AD matches the OU structure in
> 389.
>
>
>
> [17/May/2016:10:56:53 -0300] - windows_conn_connect : detected Win2k3 or
> later peer
> [17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows sync -
> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No linger to cancel on the
> connection
> [17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state before
> 573b22010001:1463493115:0:6
> [17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state after
> 573b232c:1463493414:0:6
> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync -
> windows_acquire_replica returned success (101)
> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync -
> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
> ready_to_acquire_replica -> sending_updates
> [17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state before
> 573b232c0001:1463493414:0:6
> [17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - changelog program -
> _cl5GetDBFile: found DB object 1b9d570 for database
> /opt/dirsrv/var/lib/dirsrv/slapd-RNP/changelogdb/169ce382-1b9011e6-91ddc5b4-dc63c95a_55c88d9900c8.db
>
>
> On Tue, May 17, 2016 at 10:08 AM, Alberto Viana 
> wrote:
>
>> Noriko,
>>
>> *Did you use the same version of 389-ds-base against AD on 2008 R2 and
>> 2012 R2?*
>> *389-Directory/1.3.4.8  B2016.063.1654*
>> *Please share the output frpm this command line "rpm -q 389-ds-base"?*
>>
>> *I compiled 389 manually once the package in apt repo is too old for me
>> (I'm using ubuntu 14.04 LTS). What specific info do you need?*
>> *ds-base is 1.3.4.8*
>>
>> *Does this error message follow some other detailed error messages?  Such
>> as ...*
>> *YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP error (ERROR_CODE)
>> ERROR_MESSAGE*
>> *or *
>> *YOUR_AGREEMENT: Received error [%s] when attempting to %s entry [%s]:
>> Please correct the attribute specified in the error message.  Refer to the
>> Windows Active Directory docs for more information.*
>> *If not, could you enable the replication log level and share the error
>> log with us?*
>>
>> *After enable replication log level:*
>> *[17/May/2016:09:13:18 -0300] - Attempting to add entry cn=Benedito
>> Maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp to AD for local
>> entry
>> uid=benedito.maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp*
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
>> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result code 32
>> (208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best
>> match of: 'OU=POPS,OU=EXTERNOS,OU=RNP,DC=homolog,DC=rnp' ) for add
>> operation *
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
>> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_process_total_add:
>> Cannot replay add operation.*
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
>> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the
>> connection*
>> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
>> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed to
>> obtain data to send to the consumer; LDAP error - 1*
>>
>> *Once I do not have the same OU structure on both side (for testing
>> purposes), I created 
>> "**ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp"
>> on AD side and started to get error in another OU that I have on 389 side
>> but not in AD.*
>>
>> *Is that the expected behavior?*
>>
>> *PS: In my production environment we use this strategy that what we dont
>> want to be replicated, just not create the OU structure and works fine. I
>> never found a better way to do that like a "exclude list".*
>>
>>
>> *Could you also share your Windows Sync agreement?  Do you happen to have
>> 2 Directory Servers -- one for 2008R2 and another for 2012R2, could you
>> provide both?*
>>
>>
>> *Here's my sync agreement:*
>>
>> *dn: cn=AD - DF-GTI-DC01,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping
>> tree,*
>> * cn=config*
>> *objectClass: top*
>> *objectClass: nsDSWindowsReplicationAgreement*
>> *description: Sync with HOMOLOG DF-GTI-DC01*
>> *cn: AD - DF-GTI-DC01*
>> *nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp*
>>

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Rich Megginson


On 05/17/2016 08:01 AM, Alberto Viana wrote:

Noriko,

Just to let you know, after I replicated/created the exactly same OU 
structure on both side, the replication seems to works fine. I'm still 
not sure that is the expected behavior:


Yes, it is.  Winsync does _not_ sync the OU structure - you have to set 
that up manually so that the OU structure in AD matches the OU structure 
in 389.




[17/May/2016:10:56:53 -0300] - windows_conn_connect : detected Win2k3 
or later peer
[17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No linger to cancel on 
the connection
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state 
before 573b22010001:1463493115:0:6
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state 
after 573b232c:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync - 
windows_acquire_replica returned success (101)
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State: 
ready_to_acquire_replica -> sending_updates
[17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state before 
573b232c0001:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - changelog program 
- _cl5GetDBFile: found DB object 1b9d570 for database 
/opt/dirsrv/var/lib/dirsrv/slapd-RNP/changelogdb/169ce382-1b9011e6-91ddc5b4-dc63c95a_55c88d9900c8.db



On Tue, May 17, 2016 at 10:08 AM, Alberto Viana > wrote:


Noriko,
/
/
/Did you use the same version of 389-ds-base against AD on 2008 R2
and 2012 R2?/
/389-Directory/1.3.4.8  B2016.063.1654/
/Please share the output frpm this command line "rpm -q 389-ds-base"?/

*I compiled 389 manually once the package in apt repo is too old
for me (I'm using ubuntu 14.04 LTS). What specific info do you need?*
*ds-base is 1.3.4.8*

/Does this error message follow some other detailed error
messages?  Such as .../
/YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP error
(ERROR_CODE) ERROR_MESSAGE/
/or /
/YOUR_AGREEMENT: Received error [%s] when attempting to %s entry
[%s]: Please correct the attribute specified in the error
message.  Refer to the Windows Active Directory docs for more
information./
/If not, could you enable the replication log level and share the
error log with us?/

*After enable replication log level:*
*[17/May/2016:09:13:18 -0300] - Attempting to add entry
cn=Benedito
Maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp to AD
for local entry
uid=benedito.maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result
code 32 (208D: NameErr: DSID-03100238, problem 2001
(NO_OBJECT), data 0, best match of:
'OU=POPS,OU=EXTERNOS,OU=RNP,DC=homolog,DC=rnp' ) for add operation *
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636):
windows_process_total_add: Cannot replay add operation.*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger
on the connection*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync
- agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run:
failed to obtain data to send to the consumer; LDAP error - 1*
*
*
*Once I do not have the same OU structure on both side (for
testing purposes), I created
"**ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp" on AD
side and started to get error in another OU that I have on 389
side but not in AD.*
*
*
*Is that the expected behavior?*
*
*
*PS: In my production environment we use this strategy that what
we dont want to be replicated, just not create the OU structure
and works fine. I never found a better way to do that like a
"exclude list".*


/Could you also share your Windows Sync agreement?  Do you happen
to have 2 Directory Servers -- one for 2008R2 and another for
2012R2, could you provide both?/


*Here's my sync agreement:*
*
*
*dn: cn=AD -
DF-GTI-DC01,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping tree,*
* cn=config*
*objectClass: top*
*objectClass: nsDSWindowsReplicationAgreement*
*description: Sync with HOMOLOG DF-GTI-DC01*
*cn: AD - DF-GTI-DC01*
*nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp*
*nsds7DirectoryReplicaSubtree: dc=homolog,dc=rnp*
*nsds7NewWinUserSyncEnabled: on*
*nsds7NewWinGroupSyncEnabled: on*
*nsds7WindowsDomain: homolog.rnp*
*nsDS5ReplicaRoot: dc=homolog,dc=rnp*
*nsDS5ReplicaHost: gti-df-dc01.homolog.rnp*

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Alberto Viana

Noriko,

Just to let you know, after I replicated/created the exactly same OU
structure on both side, the replication seems to works fine. I'm still not
sure that is the expected behavior:

[17/May/2016:10:56:53 -0300] - windows_conn_connect : detected Win2k3 or
later peer
[17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No linger to cancel on the
connection
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state before
573b22010001:1463493115:0:6
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time: gen state after
573b232c:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync -
windows_acquire_replica returned success (101)
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
ready_to_acquire_replica -> sending_updates
[17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state before
573b232c0001:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - changelog program -
_cl5GetDBFile: found DB object 1b9d570 for database
/opt/dirsrv/var/lib/dirsrv/slapd-RNP/changelogdb/169ce382-1b9011e6-91ddc5b4-dc63c95a_55c88d9900c8.db


On Tue, May 17, 2016 at 10:08 AM, Alberto Viana 
wrote:

> Noriko,
>
> *Did you use the same version of 389-ds-base against AD on 2008 R2 and
> 2012 R2?*
> *389-Directory/1.3.4.8  B2016.063.1654*
> *Please share the output frpm this command line "rpm -q 389-ds-base"?*
>
> *I compiled 389 manually once the package in apt repo is too old for me
> (I'm using ubuntu 14.04 LTS). What specific info do you need?*
> *ds-base is 1.3.4.8*
>
> *Does this error message follow some other detailed error messages?  Such
> as ...*
> *YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP error (ERROR_CODE)
> ERROR_MESSAGE*
> *or *
> *YOUR_AGREEMENT: Received error [%s] when attempting to %s entry [%s]:
> Please correct the attribute specified in the error message.  Refer to the
> Windows Active Directory docs for more information.*
> *If not, could you enable the replication log level and share the error
> log with us?*
>
> *After enable replication log level:*
> *[17/May/2016:09:13:18 -0300] - Attempting to add entry cn=Benedito
> Maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp to AD for local
> entry
> uid=benedito.maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp*
> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result code 32
> (208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best
> match of: 'OU=POPS,OU=EXTERNOS,OU=RNP,DC=homolog,DC=rnp' ) for add
> operation *
> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_process_total_add:
> Cannot replay add operation.*
> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the
> connection*
> *[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
> agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed to
> obtain data to send to the consumer; LDAP error - 1*
>
> *Once I do not have the same OU structure on both side (for testing
> purposes), I created 
> "**ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp"
> on AD side and started to get error in another OU that I have on 389 side
> but not in AD.*
>
> *Is that the expected behavior?*
>
> *PS: In my production environment we use this strategy that what we dont
> want to be replicated, just not create the OU structure and works fine. I
> never found a better way to do that like a "exclude list".*
>
>
> *Could you also share your Windows Sync agreement?  Do you happen to have
> 2 Directory Servers -- one for 2008R2 and another for 2012R2, could you
> provide both?*
>
>
> *Here's my sync agreement:*
>
> *dn: cn=AD - DF-GTI-DC01,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping
> tree,*
> * cn=config*
> *objectClass: top*
> *objectClass: nsDSWindowsReplicationAgreement*
> *description: Sync with HOMOLOG DF-GTI-DC01*
> *cn: AD - DF-GTI-DC01*
> *nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp*
> *nsds7DirectoryReplicaSubtree: dc=homolog,dc=rnp*
> *nsds7NewWinUserSyncEnabled: on*
> *nsds7NewWinGroupSyncEnabled: on*
> *nsds7WindowsDomain: homolog.rnp*
> *nsDS5ReplicaRoot: dc=homolog,dc=rnp*
> *nsDS5ReplicaHost: gti-df-dc01.homolog.rnp*
> *nsDS5ReplicaPort: 636*
> *nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com LDAP
> 389,OU=APLICACOES*
> * ,DC=homolog,DC=rnp*
> *nsDS5ReplicaTransportInfo: SSL*
> *nsDS5ReplicaBindMethod: SIMPLE*
> *nsDS5ReplicaCredentials:
> {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG*
>
> * 
> RERBNEJDUXhNVEZoWmpjMVlTMDVaakkyTXpBNA0KTnkwNVl6RmxOV1UwWXkxaVpHWTBaVEkwWkFBQ*
>
> * 
>

[389-users] Re: Sync problems with AD 2012 R2

2016-05-17 Thread Alberto Viana

Noriko,

*Did you use the same version of 389-ds-base against AD on 2008 R2 and 2012
R2?*
*389-Directory/1.3.4.8  B2016.063.1654*
*Please share the output frpm this command line "rpm -q 389-ds-base"?*

*I compiled 389 manually once the package in apt repo is too old for me
(I'm using ubuntu 14.04 LTS). What specific info do you need?*
*ds-base is 1.3.4.8*

*Does this error message follow some other detailed error messages?  Such
as ...*
*YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP error (ERROR_CODE)
ERROR_MESSAGE*
*or *
*YOUR_AGREEMENT: Received error [%s] when attempting to %s entry [%s]:
Please correct the attribute specified in the error message.  Refer to the
Windows Active Directory docs for more information.*
*If not, could you enable the replication log level and share the error log
with us?*

*After enable replication log level:*
*[17/May/2016:09:13:18 -0300] - Attempting to add entry cn=Benedito
Maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp to AD for local
entry
uid=benedito.maia,ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result code 32
(208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best
match of: 'OU=POPS,OU=EXTERNOS,OU=RNP,DC=homolog,DC=rnp' ) for add
operation *
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_process_total_add:
Cannot replay add operation.*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the
connection*
*[17/May/2016:09:13:18 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed to
obtain data to send to the consumer; LDAP error - 1*

*Once I do not have the same OU structure on both side (for testing
purposes), I created "**ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp"
on AD side and started to get error in another OU that I have on 389 side
but not in AD.*

*Is that the expected behavior?*

*PS: In my production environment we use this strategy that what we dont
want to be replicated, just not create the OU structure and works fine. I
never found a better way to do that like a "exclude list".*


*Could you also share your Windows Sync agreement?  Do you happen to have 2
Directory Servers -- one for 2008R2 and another for 2012R2, could you
provide both?*


*Here's my sync agreement:*

*dn: cn=AD - DF-GTI-DC01,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping
tree,*
* cn=config*
*objectClass: top*
*objectClass: nsDSWindowsReplicationAgreement*
*description: Sync with HOMOLOG DF-GTI-DC01*
*cn: AD - DF-GTI-DC01*
*nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp*
*nsds7DirectoryReplicaSubtree: dc=homolog,dc=rnp*
*nsds7NewWinUserSyncEnabled: on*
*nsds7NewWinGroupSyncEnabled: on*
*nsds7WindowsDomain: homolog.rnp*
*nsDS5ReplicaRoot: dc=homolog,dc=rnp*
*nsDS5ReplicaHost: gti-df-dc01.homolog.rnp*
*nsDS5ReplicaPort: 636*
*nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com LDAP
389,OU=APLICACOES*
* ,DC=homolog,DC=rnp*
*nsDS5ReplicaTransportInfo: SSL*
*nsDS5ReplicaBindMethod: SIMPLE*
*nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG*
* RERBNEJDUXhNVEZoWmpjMVlTMDVaakkyTXpBNA0KTnkwNVl6RmxOV1UwWXkxaVpHWTBaVEkwWkFBQ*
* 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ0FNQytucnM5R09Pbm*
* IrTGc5Q1BURw==}y3eiY+wIKrDUOvz08JXugA==*
*nsds7DirsyncCookie::
TVNEUwMAAABTrjoAO7DRAQAAWMJLBQAAA*
* ADCSwUAAOaoLC8LQH5DrKGkZbG6hSgBAAMAUFu8Kzif9UKPjH3e1siBWw*
* A5AQAA5qgsLwtAfkOsoaRlsbqFKMNLBQAAdqnRrgBktU6JZXBssjxeIesdBQAA*
*nsds5replicareapactive: 0*
*nsds5replicaLastUpdateStart: 20160517125737Z*
*nsds5replicaLastUpdateEnd: 20160517125737Z*
*nsds5replicaChangesSentSinceStartup:*
*nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
upd*
* ate started*
*nsds5replicaUpdateInProgress: FALSE*
*nsds5replicaLastInitStart: 20160517124301Z*
*nsds5replicaLastInitEnd: 20160517125236Z*
*nsds5replicaLastInitStatus: 1 connection error: operation failure - Total
upda*
* te aborted*


*In this testing environment, I just have 2012 r2 (I upgraded all DCs to
2012). Right now, I don't have any 2008 r2 to test. *

*In my production environment I have:*
*389-ds-base 1.3.2.19 + Windows 2008 r2*

On Mon, May 16, 2016 at 6:02 PM, Noriko Hosoi  wrote:

> On 05/16/2016 01:01 PM, Alberto Viana wrote:
>
> I'm trying to setup a new scenario with 389 and AD 2012 R2 (So far I'm
> using with AD 2008 R2 and everything works fine).
>
> Did you use the same version of 389-ds-base against AD on 2008 R2 and 2012
> R2?
>
> 389-Directory/1.3.4.8 B2016.063.1654
>
> Please share the output frpm this command line "rpm -q 389-ds-base"?
>
>
> Windows 2012 R2 64bits
>
> Both 2008 R2 and

[389-users] Re: Latest version of 389 for Centos 7

2016-05-17 Thread Richard Tearle

Many thanks for confirming, and sorry for the multiple posts.

On 16 May 2016 at 23:45, William Brown  wrote:

> On Mon, 2016-05-16 at 13:08 +0100, Richard Tearle wrote:
> > Hello
> >
> > What is the latest version of 389 (-ds-base) available via RPMs for
> > Centos7? Yum is telling me it's 1.3.4.0-30.el7_2, which is from June
> > last year.
> >
> > Is that correct, or have I messed up?
>
>
> That is correct. 1.3.4 is the current version in el7.2.
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
>
> --
> 389-users mailing list
> 389-users@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
>


-- 

*Richard Tearle BSc(Hons) MCP*

Senior Consultant

*Northgate Public Services (NPS)*

Mobile: +44 (0)7738 888315

Email: richard.tea...@northgateps.com

Web: www.northgate-is.com

Please consider the environment before printing this e-mail

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1908 264500 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NN.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.
--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Auditing Tool for Directory Server

[389-users] Re: Auditing Tool for Directory Server

[389-users] Re: Auditing Tool for Directory Server

[389-users] Re: Sync problems with AD 2012 R2

[389-users] x-forwarded-for

[389-users] Re: Sync problems with AD 2012 R2

[389-users] Re: Sync problems with AD 2012 R2

[389-users] Re: Sync problems with AD 2012 R2

[389-users] Re: Sync problems with AD 2012 R2

[389-users] Re: Sync problems with AD 2012 R2

[389-users] Re: Sync problems with AD 2012 R2

[389-users] Re: Latest version of 389 for Centos 7

12 matches

Site Navigation

Mail list logo

Footer information