Problem solved. It works.

Thank you all.


Il 27/09/2013 16:33, Mihai ha scritto:
> 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?
Into "Account Object Classes" you have to specify all the objectclasse
you need.
Take a look at the configuration sample provided in the embedded
environnement.

As suggested before, I invite you to perform a manually user creation
via ldif in order to catch all classes you need.

Regards,
F.

> 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] <mailto:[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/
>     <http://people.apache.org/%7Eilgrosso/>
>
>

Reply via email to