[Fedora-directory-users] FDS and OpenLDAP integration

[Matteo Angelino]

Hello,
in my organization I have a master ldap server based on openLDAP. Now  
I have installed a new ldap server (slave) based on Fedora Directory  
Server.
The openLDAP server have a replica directive in the cenfiguration  
file to replicate the modify to FDS server. Modify entry that exist  
on master server work fine.
The problem in the insert of e new user into the master server. When  
I try to insert e new user from the followind ldif, i see an error in  
the insert.

testuser.ldif:

dn: uid=testuser, dc=studenti, dc=unipmn,dc=it
givenName: TEST
postalCode: 1920
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0=
mail: roberto.pinna(a)studenti.unipmn.it
uid: testuser
uidNumber: 6763578
cn: TEST USER
carLicense: PNNRRT73B26A182A
loginShell: /bin/bash
gidNumber: 100
homeDirectory: /home/test
sn: TEST

Error from FDS error log:

Entry "uid=testuser,dc=studenti,dc=unipmn,dc=it" -- attribute  
"structuralobjectclass" not allowed

Error from slurpd (on master openLDAP server):

Error: ldap_add_s failed adding DN  
"uid=testuser,dc=studenti,dc=unipmn,dc=it": attribute  
"structuralobjectclass" not allowed

Information from reject file of the surpd:

ERROR::  
T2JqZWN0IGNsYXNzIHZpb2xhdGlvbjogYXR0cmlidXRlICJzdHJ1Y3R1cmFsb2JqZWN0Y2
  xhc3MiIG5vdCBhbGxvd2VkCg==
replica: db.mfn.unipmn.it:389
time: 1189156318.0
dn: uid=testuser,dc=studenti,dc=unipmn,dc=it
changetype: add
givenName: TEST
postalCode: 1920
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0=
uid: testuser
mail: roberto.pinna(a)studenti.unipmn.it
uidNumber: 6763578
cn: TEST USER
carLicense: PNNRRT73B26A182A
loginShell: /bin/bash
gidNumber: 100
homeDirectory: /home/test
sn: TEST
structuralObjectClass: inetOrgPerson
entryUUID: 21363b50-f16e-102b-96d1-e14b33466425
creatorsName: cn=manager,dc=unipmn,dc=it
createTimestamp: 20070907091157Z
entryCSN: 20070907091157Z#000000#00#000000
modifiersName: cn=manager,dc=unipmn,dc=it
modifyTimestamp: 20070907091157Z


I have see that the structuralobjectclass is not defined in the  
attributes available in FDS.... how can resolve the probem?

Thank's in advance

--------------------------------------------------------------
Matteo Angelino
Dipartimento di Informatica
Via Bellini 25\G
15100 Alessandria
ITALY
Tel: [phone]
Email: matteo.angelino(a)mfn.unipmn.it
--------------------------------------------------------------

[Rich Megginson]

Matteo Angelino wrote:
>  Hello,
>  in my organization I have a master ldap server based on openLDAP. Now 
>  I have installed a new ldap server (slave) based on Fedora Directory 
>  Server.
>  The openLDAP server have a replica directive in the cenfiguration file 
>  to replicate the modify to FDS server. Modify entry that exist on 
>  master server work fine.
>  The problem in the insert of e new user into the master server. When I 
>  try to insert e new user from the followind ldif, i see an error in 
>  the insert.
>
>  testuser.ldif:
>
>  dn: uid=testuser, dc=studenti, dc=unipmn,dc=it
>  givenName: TEST
>  postalCode: 1920
>  objectClass: top
>  objectClass: person
>  objectClass: inetOrgPerson
>  objectClass: posixAccount
>  userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0=
>  mail: roberto.pinna(a)studenti.unipmn.it
>  uid: testuser
>  uidNumber: 6763578
>  cn: TEST USER
>  carLicense: PNNRRT73B26A182A
>  loginShell: /bin/bash
>  gidNumber: 100
>  homeDirectory: /home/test
>  sn: TEST
>
>  Error from FDS error log:
>
>  Entry "uid=testuser,dc=studenti,dc=unipmn,dc=it" -- attribute 
>  "structuralobjectclass" not allowed
>
>  Error from slurpd (on master openLDAP server):
>
>  Error: ldap_add_s failed adding DN 
>  "uid=testuser,dc=studenti,dc=unipmn,dc=it": attribute 
>  "structuralobjectclass" not allowed
>
>  Information from reject file of the surpd:
>
>  ERROR:: 
>  T2JqZWN0IGNsYXNzIHZpb2xhdGlvbjogYXR0cmlidXRlICJzdHJ1Y3R1cmFsb2JqZWN0Y2
>   xhc3MiIG5vdCBhbGxvd2VkCg==
>  replica: db.mfn.unipmn.it:389
>  time: 1189156318.0
>  dn: uid=testuser,dc=studenti,dc=unipmn,dc=it
>  changetype: add
>  givenName: TEST
>  postalCode: 1920
>  objectClass: top
>  objectClass: person
>  objectClass: inetOrgPerson
>  objectClass: posixAccount
>  userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0=
>  uid: testuser
>  mail: roberto.pinna(a)studenti.unipmn.it
>  uidNumber: 6763578
>  cn: TEST USER
>  carLicense: PNNRRT73B26A182A
>  loginShell: /bin/bash
>  gidNumber: 100
>  homeDirectory: /home/test
>  sn: TEST
>  structuralObjectClass: inetOrgPerson
>  entryUUID: 21363b50-f16e-102b-96d1-e14b33466425
>  creatorsName: cn=manager,dc=unipmn,dc=it
>  createTimestamp: 20070907091157Z
>  entryCSN: 20070907091157Z#000000#00#000000
>  modifiersName: cn=manager,dc=unipmn,dc=it
>  modifyTimestamp: 20070907091157Z
>
>
>  I have see that the structuralobjectclass is not defined in the 
>  attributes available in FDS.... how can resolve the probem? 
I suggest adding an
operational attribute called 'structuralObjectClass' 
to Fedora DS.  Maybe you can just copy the definition of it from openldap.
>  Thank's in advance
>
>  --------------------------------------------------------------
>  Matteo Angelino
>  Dipartimento di Informatica
>  Via Bellini 25\G
>  15100 Alessandria
>  ITALY
>  Tel: [phone]
>  Email: matteo.angelino(a)mfn.unipmn.it
>  --------------------------------------------------------------
>
>
>
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Pierangelo Masarati]

Richard Megginson wrote:

> > I have see that the structuralobjectclass is not defined in the 
> > attributes available in FDS.... how can resolve the probem?
>  I suggest adding an operational attribute called 'structuralObjectClass' 
>  to Fedora DS.  Maybe you can just copy the definition of it from openldap. 
Since the structuralObjectClass attribute is supposed to have a very 
special meaning for the DSA (RFC 4512), just adding it as a user 
attribute seems to me quite a broken approach.  Provided you're running 
a decent version of OpenLDAP, you should be able to filter out undesired 
attributes from the replication process.  For example, in slapd.conf 
(from slapd.conf(5) man page of OpenLDAP 2.3, but the feature exists 
since OpenLDAP 2.1, I think)

replica [...]
	attr!=structuralObjectClass

will prevent slurpd from replicating the negated attribute list.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  [phone]
Mobile:  [phone]
Email:   pierangelo.masarati(a)sys-net.it
---------------------------------------

[Pierangelo Masarati]

Pierangelo Masarati wrote:

>  Since the structuralObjectClass attribute is supposed to have a very
>
>  special meaning for the DSA (RFC 4512), just adding it as a user 
>  attribute seems to me quite a broken approach.  Provided you're running 
>  a decent version of OpenLDAP, you should be able to filter out undesired 
>  attributes from the replication process.  For example, in slapd.conf 
>  (from slapd.conf(5) man page of OpenLDAP 2.3, but the feature exists 
>  since OpenLDAP 2.1, I think)
>  
>  replica [...]
>      attr!=structuralObjectClass
>  
>  will prevent slurpd from replicating the negated attribute list. 
Just for the records: a custom patch in this sense was developed by 
SysNet back in the old times of OpenLDAP 2.0 exactly for the purpose of 
replicating an OpenLDAP server to a proprietary LDAP server that didn't 
like many operational attributes slurpd was willing to push in.  It also 
provided partial subtree replication capabilities.

A similar patch was prepared in the meanwhile by Symas and the two 
merged into OpenLDAP 2.1.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  [phone]
Mobile:  [phone]
Email:   pierangelo.masarati(a)sys-net.it
---------------------------------------

[Matteo Angelino]

Thank's
I have used the first solution, I hv added the followin line in my  
slapd.conf

attr!=structuralObjectClass

I have added othe two line in my slapd.conf

attr!=entryUUID
attr!=entryCSN

with this 3 line the replication work fine.

On Sep 7, 2007, at 6:20 PM, Pierangelo Masarati wrote:

>  Pierangelo Masarati wrote:
>
> > Since the structuralObjectClass attribute is supposed to have a  
> > very special meaning for the DSA (RFC 4512), just adding it as a  
> > user attribute seems to me quite a broken approach.  Provided  
> > you're running a decent version of OpenLDAP, you should be able to  
> > filter out undesired attributes from the replication process.  For  
> > example, in slapd.conf (from slapd.conf(5) man page of OpenLDAP  
> > 2.3, but the feature exists since OpenLDAP 2.1, I think)
> > replica [...]
> >     attr!=structuralObjectClass
> > will prevent slurpd from replicating the negated attribute list.
>
>  Just for the records: a custom patch in this sense was developed by  
>  SysNet back in the old times of OpenLDAP 2.0 exactly for the  
>  purpose of replicating an OpenLDAP server to a proprietary LDAP  
>  server that didn't like many operational attributes slurpd was  
>  willing to push in.  It also provided partial subtree replication  
>  capabilities.
>
>  A similar patch was prepared in the meanwhile by Symas and the two  
>  merged into OpenLDAP 2.1.
>
>  p.
>
>
>
>  Ing. Pierangelo Masarati
>  OpenLDAP Core Team
>
>  SysNet s.r.l.
>  via Dossi, 8 - 27100 Pavia - ITALIA
>  http://www.sys-net.it
>  ---------------------------------------
>  Office:  [phone]
>  Mobile:  [phone]
>  Email:   pierangelo.masarati(a)sys-net.it
>  ---------------------------------------
>
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users 
--------------------------------------------------------------
Matteo Angelino
Dipartimento di Informatica
Via Bellini 25\G
15100 Alessandria
ITALY
Tel: [phone]
Email: matteo.angelino(a)mfn.unipmn.it
--------------------------------------------------------------

[Rich Megginson]

Matteo Angelino wrote:
>  Thank's
>  I have used the first solution, I hv added the followin line in my 
>  slapd.conf
>
>  attr!=structuralObjectClass
>
>  I have added othe two line in my slapd.conf
>
>  attr!=entryUUID
>  attr!=entryCSN
>
>  with this 3 line the replication work fine. 
Great!  I've added this information
here - 
http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
>  On Sep 7, 2007, at 6:20 PM, Pierangelo Masarati wrote:
>
> > Pierangelo Masarati wrote:
> >
> >> Since the structuralObjectClass attribute is supposed to have a very 
> >> special meaning for the DSA (RFC 4512), just adding it as a user 
> >> attribute seems to me quite a broken approach.  Provided you're 
> >> running a decent version of OpenLDAP, you should be able to filter 
> >> out undesired attributes from the replication process.  For example, 
> >> in slapd.conf (from slapd.conf(5) man page of OpenLDAP 2.3, but the 
> >> feature exists since OpenLDAP 2.1, I think)
> >> replica [...]
> >>     attr!=structuralObjectClass
> >> will prevent slurpd from replicating the negated attribute list.
> >
> > Just for the records: a custom patch in this sense was developed by 
> > SysNet back in the old times of OpenLDAP 2.0 exactly for the purpose 
> > of replicating an OpenLDAP server to a proprietary LDAP server that 
> > didn't like many operational attributes slurpd was willing to push 
> > in.  It also provided partial subtree replication capabilities.
> >
> > A similar patch was prepared in the meanwhile by Symas and the two 
> > merged into OpenLDAP 2.1.
> >
> > p.
> >
> >
> >
> > Ing. Pierangelo Masarati
> > OpenLDAP Core Team
> >
> > SysNet s.r.l.
> > via Dossi, 8 - 27100 Pavia - ITALIA
> > http://www.sys-net.it
> > ---------------------------------------
> > Office:  [phone]
> > Mobile:  [phone]
> > Email:   pierangelo.masarati(a)sys-net.it
> > ---------------------------------------
> >
> >
> > -- 
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>  --------------------------------------------------------------
>  Matteo Angelino
>  Dipartimento di Informatica
>  Via Bellini 25\G
>  15100 Alessandria
>  ITALY
>  Tel: [phone]
>  Email: matteo.angelino(a)mfn.unipmn.it
>  --------------------------------------------------------------
>
>
>
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Pierangelo Masarati]

Richard Megginson wrote:

>  Great!  I've added this information here - 
>  http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration 
Rich, I've cleaned up that entry, please check.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  [phone]
Mobile:  [phone]
Email:   pierangelo.masarati(a)sys-net.it
---------------------------------------

[Rich Megginson]

Pierangelo Masarati wrote:
>  Richard Megginson wrote:
>
> > Great!  I've added this information here - 
> > http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
>
>  Rich, I've cleaned up that entry, please check. 
Excellent.  Thanks!
>  p.
>
>
>
>  Ing. Pierangelo Masarati
>  OpenLDAP Core Team
>
>  SysNet s.r.l.
>  via Dossi, 8 - 27100 Pavia - ITALIA
>  http://www.sys-net.it
>  ---------------------------------------
>  Office:  [phone]
>  Mobile:  [phone]
>  Email:   pierangelo.masarati(a)sys-net.it
>  ---------------------------------------
>
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Del]

Pierangelo Masarati wrote:
>  Richard Megginson wrote:
>  
> > Great!  I've added this information here - 
> > http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
>  
>  Rich, I've cleaned up that entry, please check. 
That entry would make more sense if it began with:

There are ways to sync data from OpenLDAP to Fedora DS.  NOTE: sync is one way only.

instead of:

There are ways to sync data between OpenLDAP and Fedora DS. NOTE: sync is one way only.

"between X and Y" implies two way, but then in the next sentence you
say that it is one way only -- which way is supported and which way
is not, is not specified.

... and I'm making the assumption that "slapd.conf" refers to the
OpenLDAP slapd.conf file, and that the sync is from OpenLDAP to FDS,
but like I said, that's not specified in the article.

-- 
Del
Babel Com Australia
http://www.babel.com.au/
ph: 02 9368 0728
fax: [phone]

[Rich Megginson]

Del wrote:
>  Pierangelo Masarati wrote:
> > Richard Megginson wrote:
> >
> >> Great!  I've added this information here - 
> >> http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
> >
> > Rich, I've cleaned up that entry, please check.
>
>  That entry would make more sense if it began with:
>
>  There are ways to sync data from OpenLDAP to Fedora DS.  NOTE: sync is 
>  one way only.
>
>  instead of:
>
>  There are ways to sync data between OpenLDAP and Fedora DS. NOTE: sync 
>  is one way only.
>
>  "between X and Y" implies two way, but then in the next sentence you
>  say that it is one way only -- which way is supported and which way
>  is not, is not specified. 
But there are ways to sync data from Fedora DS to
OpenLDAP also.  You 
just can't do both directions at the same time.  How could I word that 
appropriately?
>  ... and I'm making the assumption that "slapd.conf" refers to the
>  OpenLDAP slapd.conf file, 
Is there another one?
>  and that the sync is from OpenLDAP to FDS,
>  but like I said, that's not specified in the article. 
The section heading is
"Replication from OpenLDAP to Fedora DS" - how 
should this be specified?

[Del]

Richard Megginson wrote:
> >>> Great!  I've added this information here - 
> >>> http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
> >>
> >> Rich, I've cleaned up that entry, please check.
> >
> > That entry would make more sense if it began with:
> >
> > There are ways to sync data from OpenLDAP to Fedora DS.  NOTE: sync is 
> > one way only.
> >
> > instead of:
> >
> > There are ways to sync data between OpenLDAP and Fedora DS. NOTE: sync 
> > is one way only.
> >
> > "between X and Y" implies two way, but then in the next sentence you
> > say that it is one way only -- which way is supported and which way
> > is not, is not specified. 
I've added a bit more wording to that page to make things clear.

-- 
Del
Babel Com Australia
http://www.babel.com.au/
ph: 02 9368 0728
fax: [phone]

[Pierangelo Masarati]

Richard Megginson wrote:

>  But there are ways to sync data from Fedora DS to OpenLDAP also. 
> You
>  just can't do both directions at the same time.  How could I word that
>  appropriately? 
Can you elaborate on that?  From the Wiki, it seems that there are some,
but they're undocumented.

The other way 'round (OL => FDS), one could try out OpenLDAP's
slapo-accesslog(5) in the changelog-like variant (haven't tested, could
need some hacking).  THis should work fine with changelog (Retro
Changelog).

Or (and it would probably be a big plus for RFC 4533) FDS could be added
a plugin that makes use of LDAP Sync.  I note that, for applications
that do not want to reinvent the wheel, OpenLDAP's libldap that ships
with 2.4 provides a ldap_sync API that hides RFC 4533 details, so one
only needs to deal with making use of the results of the various phases
of the sync replication.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  [phone]
Mobile:  [phone]
Email:   pierangelo.masarati(a)sys-net.it
---------------------------------------

[Rich Megginson]

Pierangelo Masarati wrote:
>  Richard Megginson wrote:
>
>    
> > But there are ways to sync data from Fedora DS to OpenLDAP also.  You
> > just can't do both directions at the same time.  How could I word that
> > appropriately?
> >     
>
>  Can you elaborate on that?  From the Wiki, it seems that there are some,
>  but they're undocumented.
>     
I haven't had time to properly test and document this, but there are at 
least 3 ways that I know of.
1) Enable audit logging, and use a process to periodically read from the 
audit log and send those changes to another ldap server.
2) Enable audit logging, but use a named pipe instead of a file.
1 and 2 could probably be a Net::LDAP perl script or a python-ldap 
script - read in the LDIF change records from the audit log, convert to 
LDAP add/modify/delete commands.
3) Use the Retro Changelog in conjunction with persistent search.  This 
could also be a script (if the LDAP client implementation understands 
Fedora DS persistent search) that does basically the same thing as 1 and 
2 above.

>  The other way 'round (OL => FDS), one could try out
> OpenLDAP's
>  slapo-accesslog(5) in the changelog-like variant (haven't tested, could
>  need some hacking).  THis should work fine with changelog (Retro
>  Changelog).
>
>  Or (and it would probably be a big plus for RFC 4533) FDS could be added
>  a plugin that makes use of LDAP Sync.  I note that, for applications
>  that do not want to reinvent the wheel, OpenLDAP's libldap that ships
>  with 2.4 provides a ldap_sync API that hides RFC 4533 details, so one
>  only needs to deal with making use of the results of the various phases
>  of the sync replication.
>     
That's good to know.  Thanks!
>  p.
>
>
>
>  Ing. Pierangelo Masarati
>  OpenLDAP Core Team
>
>  SysNet s.r.l.
>  via Dossi, 8 - 27100 Pavia - ITALIA
>  http://www.sys-net.it
>  ---------------------------------------
>  Office:  [phone]
>  Mobile:  [phone]
>  Email:   pierangelo.masarati(a)sys-net.it
>  ---------------------------------------
>
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>