dsidm not work with imported openldap accounts

[Alberto Crescente]

Hello, I would like to migrate my old openldap server to 389-ds (CentOS 
8). I tried to upload the old users from the openldap server into 
389-ds, but if I then try to use the dsidm command I get the following 
error message: "Error: No object exists given the filter criteria ... " 
# john, people, example.com dn: uid=john,ou=people,dc=example,dc=com 
objectClass: top objectClass: person objectClass: posixAccount 
objectClass: shadowAccount uid: john cn: John uidNumber: 5000 gidNumber: 
5000 homeDirectory: /home/john shadowLastChange: 18170 loginShell: 
/bin/bash gecos: John Brown shadowExpire: 24444 sn: Brown Is it a schema 
problem? Does dsidm only work with accounts that have the schema of DS 
1.4? In 389-ds there is an openldap_to_ds migration script, but it seems 
to me that it keeps the same schema for the account after migration, at 
this point it is better to recreate all the accounts with the new DS 1.4 
schema starting from the openldap data?
# john, people, example.com dn: uid=john,ou=people,dc=example,dc=com 
objectClass: top objectClass: nsPerson objectClass: nsAccount 
objectClass: nsOrgPerson objectClass: posixAccount objectClass: 
shadowAccount uid: john cn: John Brown uidNumber: 5000 gidNumber: 5000 
homeDirectory: /home/john shadowLastChange: 18170 loginShell: /bin/bash 
displayName: John Brown shadowExpire: 24444 Best regards, Alberto 
Crescente.

[Mark Reynolds]

Hi Alberto

On 6/1/22 2:26 AM, Alberto Crescente wrote:
> Hello, I would like to migrate my old openldap server to 389-ds 
> (CentOS 8). I tried to upload the old users from the openldap server 
> into 389-ds, but if I then try to use the dsidm command I get the 
> following error message: "Error: No object exists given the filter 
> criteria ... "
> # john, people, example.com dn: uid=john,ou=people,dc=example,dc=com 
> objectClass: top objectClass: person objectClass: posixAccount 
> objectClass: shadowAccount uid: john cn: John uidNumber: 5000 
> gidNumber: 5000 homeDirectory: /home/john shadowLastChange: 18170 
> loginShell: /bin/bash gecos: John Brown shadowExpire: 24444 sn: Brown 
> Is it a schema problem?

Sort of...  dsidm is an opinionated tool, and it does expect certain 
schema to be place to work correctly.
> Does dsidm only work with accounts that have the schema of DS 1.4? In 
> 389-ds there is an openldap_to_ds migration script, but it seems to me 
> that it keeps the same schema for the account after migration, at this 
> point it is better to recreate all the accounts with the new DS 1.4 
> schema starting from the openldap data?

So yes as you noted below if the migration tool also added these 
objectclasses it would probably work:

objectClass: nsPerson (requires attributes: displayName and cn)
objectClass: nsAccount
objectClass: nsOrgPerson

William did all the openldap migration work so I'd like to get his input 
on this, but to me it makes sense to have any "migration tool" we 
provide to be compatible with the CLI tools we ship. This should be a 
simple change to lib389 to get this working.

Regards,

Mark
> # john, people, example.com dn: uid=john,ou=people,dc=example,dc=com 
> objectClass: top objectClass: nsPerson objectClass: nsAccount 
> objectClass: nsOrgPerson objectClass: posixAccount objectClass: 
> shadowAccount uid: john cn: John Brown uidNumber: 5000 gidNumber: 5000 
> homeDirectory: /home/john shadowLastChange: 18170 loginShell: 
> /bin/bash displayName: John Brown shadowExpire: 24444 Best regards, 
> Alberto Crescente.
>
> 389-users mailing list [e-mail]
> To unsubscribe send an email [e-mail]
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:https://lists.fedoraproject.org/archives/list/[e-mail]....
> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure

[William Brown]

> On 1 Jun 2022, at 23:31, Mark Reynolds  wrote:
>
> Hi Alberto
>
> On 6/1/22 2:26 AM, Alberto Crescente wrote:
> > Hello, I would like to migrate my old openldap server to 389-ds (CentOS 8). I tried to upload
> > the old users from the openldap server into 389-ds, but if I then try to use the dsidm command I get the following
> > error message: "Error: No object exists given the filter criteria ... "
> >
> > # john, people, example.com
> > dn: uid=john,ou=people,dc=example,dc=com
> > objectClass: top
> > objectClass: person
> > objectClass: posixAccount
> > objectClass: shadowAccount
> > uid: john
> > cn: John
> > uidNumber: 5000
> > gidNumber: 5000
> > homeDirectory: /home/john
> > shadowLastChange: 18170
> > loginShell: /bin/bash
> > gecos: John Brown
> > shadowExpire: 24444
> > sn: Brown
> >
> > Is it a schema problem?
>
> Sort of...  dsidm is an opinionated tool, and it does expect certain schema to be place to work correctly.
> > Does dsidm only work with accounts that have the schema of DS 1.4?
> > In 389-ds there is an openldap_to_ds migration script, but it seems to me that it keeps the same
> > schema for the account after migration, at this point it is better to recreate all the accounts with the new DS 1.4 schema
> > starting from the openldap data?
>
> So yes as you noted below if the migration tool also added these objectclasses it would probably work:
>
> objectClass: nsPerson (requires attributes: displayName and cn)
> objectClass: nsAccount
> objectClass: nsOrgPerson
>
> William did all the openldap migration work so I'd like to get his input on this, but to me it makes sense to have any "migration tool" we provide to be compatible with the CLI tools we ship.  This should be a simple change to lib389 to get this working.

Well, there are two sides to this.

nsPerson/nsAccount are designed to fix a number of "unfixable" issues from the legacy schemas including names, ssh key storage and more.

But when we import data from openldap, we import it to "respect the data as it was". It's one thing to migrate, it's another to "munge the data" as we import it.

So I don't think we want to change openldap_to_ds to auto-add nsPerson/nsAccount, because that involves data transforms that the admin should be aware of.

But we also want dsidm to represent "best practice" so using those objectClasses is the right thing to do.

I think this is a case where we need a post-migrate tool that can do these transforms, in a way that the admin is comfortable with.
> Regards,
>
> Mark
> > # john, people, example.com
> > dn: uid=john,ou=people,dc=example,dc=com
> > objectClass: top
> > objectClass: nsPerson
> >
> > objectClass: nsAccount
> >
> > objectClass: nsOrgPerson
> >
> > objectClass: posixAccount
> > objectClass: shadowAccount
> > uid: john
> > cn: John Brown
> > uidNumber: 5000
> > gidNumber: 5000
> > homeDirectory: /home/john
> > shadowLastChange: 18170
> > loginShell: /bin/bash
> > displayName: John Brown
> > shadowExpire: 24444
> >
> > Best regards,
> > Alberto Crescente.
> >
> > 389-users mailing list -- 
> > [e-mail]
> >
> > To unsubscribe send an email to 
> > [e-mail]
> >
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> >
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail]....
> >
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>
> -- 
> Directory Server Development Team
>
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia