The configuration [2] depends of the configuration of the ldap schema. So it can't be followed step by step. It would be useful to attache the output of # slapcat command to the tutorial [2].
For example, in my ldap schema I have no "inetOrgPerson" object class, but I do have object classes: organizationalPerson, organizationalUnit etc. Please check the slapcat.txt attached to my previous email. Is it ok to replace "Account Object Classes inetOrgPerson" of the tutorial with the "Account Object Classes inetOrgPerson in my config? Is is ok to replace "Object Classes to Synchronize inetOrgPerson" with "Object Classes to Synchronize organizationalPerson" in my config? Of course, many other variables are changed in my case, different company name, host IP, cn, ou etc. It is difficult for me to follow the tutorial because my environment is different and every variable must be replaced with something else. Without an output of the slapcat command of the server for which that tutorial works, is difficult for me to gues for example where did "inetOrgPerson" camed from. I am a little bit confused right now. Thank you. On Fri, Sep 27, 2013 at 5:07 PM, Francesco Chicchiriccò <[email protected] > wrote: > On 27/09/2013 15:58, Mathias Holdt wrote: > > Hi > > And sorry for interrupting, but I had a similar problem (on the AD > > connector though). I could import users, edit them, and delete them, > > but provisioning with a password resulted in an error (cant remember > > the exact error, so I am not sure that you are experiencing the same > > problem). > > > > The solution was quite easy though. It turned out that the connector > > required SSL to provision users with a password. Once I enabled SSL > > (and switched to port 636), provisioning started without errors. > > Hi Mathias, > this is only applicable to the AD connector; as reported by [1], in > fact, SSL is needed to perform password provisioning, as required in > turn by Active Directory. > > The configuration reported in [2] works out-of-the-box for different > LDAP servers, and does actually propagate passwords, with no need for > SSL (as the LDAPv3 protocol actually allows). > > Regards. > > [1] https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482 > [2] > > http://blog.tirasa.net/blogs/index.php/ilgrosso/unlock-full-ldap-features-in > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/ > >
