DNA Plugin NextValue automatically added every time for same uid

[DaV]

Hi,
I find the DNA Plugin NextValue attribute will automatically added every time for same uid.

version: 389-ds-base-1.3.8.4-15.el7.x86_64

This is the server side configuration:
> dn: cn=uidNumber,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: uidNumber
> dnaType: uidNumber
> dnaMagicRegen: 99999
> dnaFilter: (objectclass=posixAccount)
> dnaScope: dc=example,dc=com
> dnaNextValue: 5007
> dnaMaxValue: 9999
> dnaThreshold: 200
> creatorsName: cn=directory manager
> modifiersName: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> createTimestamp: 20190822054416Z
> modifyTimestamp: 20200619040000Z

User attribute source is Windows AD, I have nsDSWindowsReplicationAgreement which sync posix attribute from AD to 389ds.
When I fill magic number 99999 on AD side, user will get a UidNumber through DNA plugin. For example, an user get a uidNumber 5007 for the first sync, when I update user entry attribute(add telephone), this user will get a new uidNumber 5008 for the second sync.
I don't know whether this is normal.

Sincerely,
--
DaV

[William Brown]

> On 23 Jun 2020, at 17:08, DaV  wrote:
>
> Hi,
> I find the DNA Plugin NextValue attribute will automatically added every time for same uid.
>
> version: 389-ds-base-1.3.8.4-15.el7.x86_64
>
> This is the server side configuration:
> > dn: cn=uidNumber,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > objectClass: top
> > objectClass: extensibleObject
> > cn: uidNumber
> > dnaType: uidNumber
> > dnaMagicRegen: 99999
> > dnaFilter: (objectclass=posixAccount)
> > dnaScope: dc=example,dc=com
> > dnaNextValue: 5007
> > dnaMaxValue: 9999
> > dnaThreshold: 200
> > creatorsName: cn=directory manager
> > modifiersName: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > createTimestamp: 20190822054416Z
> > modifyTimestamp: 20200619040000Z
>
> User attribute source is Windows AD, I have nsDSWindowsReplicationAgreement which sync posix attribute from AD to 389ds.
> When I fill magic number 99999 on AD side, user will get a UidNumber through DNA plugin. For example, an user get a uidNumber 5007 for the first sync, when I update user entry attribute(add telephone), this user will get a new uidNumber 5008 for the second sync.
> I don't know whether this is normal.

So every time you winsync, it says "oh, ad has uidnumber 99999, 389 is 5007" and it will change it to 99999. When the dna plugin run it then sees "well it's 9999, better generate a new id"

The conflict is occuring here because you sync in the 99999 attr from ad. You probably should remove that, and it will prevent the issue.

How to make this work with DNA though, is another question ...
> Sincerely,
>
> DaV
>
> 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]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[DaV]

Yes, it is.
So I have to change the UidNumber to 5007 on AD side manually after the first winsync. 
emm, not convenient.

Sincerely,
--
DaV

On Wed, Jun 24, 2020, at 09:56, William Brown wrote:
> > On 23 Jun 2020, at 17:08, DaV  wrote:
> >
> > Hi,
> > I find the DNA Plugin NextValue attribute will automatically added every time for same uid.
> >
> > version: 389-ds-base-1.3.8.4-15.el7.x86_64
> >
> > This is the server side configuration:
> > > dn: cn=uidNumber,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > > objectClass: top
> > > objectClass: extensibleObject
> > > cn: uidNumber
> > > dnaType: uidNumber
> > > dnaMagicRegen: 99999
> > > dnaFilter: (objectclass=posixAccount)
> > > dnaScope: dc=example,dc=com
> > > dnaNextValue: 5007
> > > dnaMaxValue: 9999
> > > dnaThreshold: 200
> > > creatorsName: cn=directory manager
> > > modifiersName: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > > createTimestamp: 20190822054416Z
> > > modifyTimestamp: 20200619040000Z
> >
> > User attribute source is Windows AD, I have nsDSWindowsReplicationAgreement which sync posix attribute from AD to 389ds.
> > When I fill magic number 99999 on AD side, user will get a UidNumber through DNA plugin. For example, an user get a uidNumber 5007 for the first sync, when I update user entry attribute(add telephone), this user will get a new uidNumber 5008 for the second sync.
> > I don't know whether this is normal.
>
> So every time you winsync, it says "oh, ad has uidnumber 99999, 389 is 
> 5007" and it will change it to 99999. When the dna plugin run it then 
> sees "well it's 9999, better generate a new id"
>
> The conflict is occuring here because you sync in the 99999 attr from 
> ad. You probably should remove that, and it will prevent the issue.
>
> How to make this work with DNA though, is another question ...
> > Sincerely,
> >
> > DaV
> >
> > 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]....
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 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]....

[William Brown]

> On 24 Jun 2020, at 16:43, DaV  wrote:
>
> Yes, it is.
> So I have to change the UidNumber to 5007 on AD side manually after the first winsync. 
> emm, not convenient.

Yep ... I think DNA was designed with different use cases in mind :(

Your best bet may to be avoiding DNA completely, and using AD/an external source to allocate uidNumbers that flow to 389 instead. :(
> Sincerely,
>
> DaV
>
> On Wed, Jun 24, 2020, at 09:56, William Brown wrote:
> > > On 23 Jun 2020, at 17:08, DaV  wrote:
> > >
> > > Hi,
> > > I find the DNA Plugin NextValue attribute will automatically added every time for same uid.
> > >
> > > version: 389-ds-base-1.3.8.4-15.el7.x86_64
> > >
> > > This is the server side configuration:
> > > > dn: cn=uidNumber,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > > > objectClass: top
> > > > objectClass: extensibleObject
> > > > cn: uidNumber
> > > > dnaType: uidNumber
> > > > dnaMagicRegen: 99999
> > > > dnaFilter: (objectclass=posixAccount)
> > > > dnaScope: dc=example,dc=com
> > > > dnaNextValue: 5007
> > > > dnaMaxValue: 9999
> > > > dnaThreshold: 200
> > > > creatorsName: cn=directory manager
> > > > modifiersName: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > > > createTimestamp: 20190822054416Z
> > > > modifyTimestamp: 20200619040000Z
> > >
> > > User attribute source is Windows AD, I have nsDSWindowsReplicationAgreement which sync posix attribute from AD to 389ds.
> > > When I fill magic number 99999 on AD side, user will get a UidNumber through DNA plugin. For example, an user get a uidNumber 5007 for the first sync, when I update user entry attribute(add telephone), this user will get a new uidNumber 5008 for the second sync.
> > > I don't know whether this is normal.
> >
> > So every time you winsync, it says "oh, ad has uidnumber 99999, 389 is 
> > 5007" and it will change it to 99999. When the dna plugin run it then 
> > sees "well it's 9999, better generate a new id"
> >
> > The conflict is occuring here because you sync in the 99999 attr from 
> > ad. You probably should remove that, and it will prevent the issue.
> >
> > How to make this work with DNA though, is another question ...
> > > Sincerely,
> > >
> > > DaV
> > >
> > > 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]....
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 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]....
>
> 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]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs