[389-users] Re: replication problems

[William Brown]

So reading these frames, it's likely that this is the assert condition failing:

(vs->num >= VALUESET_ARRAY_SORT_THRESHOLD) && (vs->sorted[0] < vs->num)

This is because vs->sorted exists, and vs->num >= threshhold (10), so as a 
result, this would indicate that vs->sorted[0] has a problem where it must be 
equal to or greater than vs->num.

Is is still possible to seethe content of the vs->sorted array? I think you 
could do:

frame 3
print *vs->sorted@21

Sorry about the delay in responding to this, things have been hectic for me. 



> On 29 Apr 2020, at 23:40, Alberto Viana  wrote:
> 
> William,
> 
> Here's:
> 
> Frame9:
> https://gist.github.com/albertocrj/87bf4a010bf2f7e1f97ef3ee72ee44df
> 
> Frame7:
> https://gist.github.com/albertocrj/840f15e5df10cad0e2977cd030abdba4
> 
> Frame6:
> https://gist.github.com/albertocrj/befb7144b86bc4af86b9a2e0be0293a1
> 
> Thank you
> 
> Alberto Viana
> 
> On Wed, Apr 22, 2020 at 11:09 PM William Brown  wrote:
> 
> 
> > On 23 Apr 2020, at 06:59, Alberto Viana  wrote:
> > 
> > Mark,
> > 
> > On frame 9:
> > 
> > It's go until p *mod->mod_bvalues[20]
> > 
> > (gdb)  p *mod->mod_bvalues[21]
> > Cannot access memory at address 0x0
> > 
> > On frame 7:
> > It's go until p *replacevals[20]
> > 
> > (gdb) p *replacevals[21]
> > Cannot access memory at address 0x0
> 
> Yep, but we need to see all the outputs from 0 -> 20 and 0 -> 21 respectively 
> :) So copy paste the full out put please! Thanks for your patience with this. 
> 
> > 
> > On frame 6:
> > (gdb) frame 6
> > #6  0x77ada6fa in entry_delete_present_values_wsi_multi_valued 
> > (e=0x7fff8401f500, type=0x7fff84012780 "memberOf", vals=0x0, 
> > csn=0x7fff967fb340, urp=8, mod_op=2, replacevals=0x7fff840127c0)
> > at ldap/servers/slapd/entrywsi.c:777
> > 777valueset_purge(a, >a_present_values, csn);
> > (gdb) print *a
> > $278 = {a_type = 0x7fff84022b30 "memberOf", a_present_values = {num = 21, 
> > max = 32, sorted = 0x7fff84023ad0, va = 0x7fff84022b50}, a_flags = 4, 
> > a_plugin = 0x6c7e80, a_deleted_values = {num = 0, max = 0,
> > sorted = 0x0, va = 0x0}, a_listtofree = 0x0, a_next = 0x7fff84023c00, 
> > a_deletioncsn = 0x7fff840247c0, a_mr_eq_plugin = 0x0, a_mr_ord_plugin = 
> > 0x0, a_mr_sub_plugin = 0x0}
> > (gdb) print *a->a_present_values
> > Structure has no component named operator*.
> > (gdb) print *a->a_present_values.va[0]
> > 
> > 
> > Thanks,
> > 
> > Alberto Viana
> > 
> > On Wed, Apr 22, 2020 at 4:57 PM Mark Reynolds  wrote:
> > Goto frame 9 and start printing the mod:
> > 
> > (gdb) p *mod
> > 
> > (gdb) print i
> > 
> > (gdb) p *mod->mod_bvalues[0]
> > 
> > (gdb) p *mod->mod_bvalues[1]
> > 
> > ... Keep doing that unitl its NULL
> > 
> > 
> > 
> > Then goto frame 7
> > 
> > (gdb) p *replacevals
> > 
> > (gdb) p *replacevals[0]
> > 
> > (gdb) p *replacevals[1]
> > 
> > --- Keeping doing this until its NULL
> > 
> > 
> > 
> > Then goto frame 6
> > 
> > (gdb) print *a
> > 
> > (gdb) print *a->a_present_values
> > 
> > (gdb) print *a->a_present_values.va[0]
> > 
> > (gdb) print *a->a_present_values.va[1]
> > 
> > --- Keeping doing this until its NULL
> > 
> > 
> > 
> > Thanks,
> > Mark
> > 
> > 
> > 
> > On 4/22/20 3:43 PM, Alberto Viana wrote:
> >> Mark,
> >> 
> >> Yes, I'm  in frame 3, and No, I do not know what modification is, sorry. I 
> >> think thats what I'm  trying to find out, why one of the servers always 
> >> crash if I enable the replication between 2 389.
> >> 
> >> Maybe reconfigure my replication, enable debug log and see where stops?
> >> 
> >> What else can I do?
> >> 
> >> Thanks
> >> 
> >> 
> >> On Wed, Apr 22, 2020 at 4:34 PM Mark Reynolds  wrote:
> >> 
> >> 
> >> On 4/22/20 3:27 PM, Alberto Viana wrote:
> >>> Mark,
> >>> 
> >>> Here's: 
> >>> (gdb) where
> >>> #0  0x7455399f in raise () at /lib64/libc.so.6
> >>> #1  0x7453dcf5 in abort () at /lib64/libc.so.6
> >>> #2  0x75430cd0 in PR_Assert () at /lib64/libnspr4.so
> >>> #3  0x77b71627 in slapi_valueset_done (vs=0x7fff8c022aa8) at 
> >>> ldap/servers/slapd/valueset.c:471
> >>> #4  0x77b72257 in valueset_array_purge (a=0x7fff8c022aa0, 
> >>> vs=0x7fff8c022aa8, csn=0x7fff977fd340) at 
> >>> ldap/servers/slapd/valueset.c:804
> >>> #5  0x77b723c5 in valueset_purge (a=0x7fff8c022aa0, 
> >>> vs=0x7fff8c022aa8, csn=0x7fff977fd340) at 
> >>> ldap/servers/slapd/valueset.c:834
> >>> #6  0x77ada6fa in entry_delete_present_values_wsi_multi_valued 
> >>> (e=0x7fff8c01f500, type=0x7fff8c012780 "memberOf", vals=0x0, 
> >>> csn=0x7fff977fd340, urp=8, mod_op=2, replacevals=0x7fff8c0127c0)
> >>> at ldap/servers/slapd/entrywsi.c:777
> >>> #7  0x77ada20d in entry_delete_present_values_wsi 
> >>> (e=0x7fff8c01f500, type=0x7fff8c012780 "memberOf", vals=0x0, 
> >>> csn=0x7fff977fd340, urp=8, mod_op=2, replacevals=0x7fff8c0127c0)
> >>> at ldap/servers/slapd/entrywsi.c:623
> >>> #8  0x77adaa7a in entry_replace_present_values_wsi 
> >>> 

[389-users] Re: pwadmin not working

[Alberto Viana]

William,

I will try it tomorrow, but a reference about
"nsslapd-allow-hashed-passwords" in
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/password_administrators
make
senses to me.


Thanks anyway.

Alberto Viana

On Tue, May 5, 2020 at 8:58 PM William Brown  wrote:

>
>
> > On 6 May 2020, at 09:09, Alberto Viana  wrote:
> >
> > William
> >
> > I want to let this user bypass the policy and add a pre-hashed password,
>
> If you want to add a pre-hashed password here, you'll need to change the
> password-migrate flag in cn=config, load that password, then unset the
> password migrate flag.
>
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/core_server_configuration_reference#nsslapd-allow-hashed-passwords
>
>
>
> > I also have a global policy and some OU policies level. On this OU
> OU=POP-PA,dc=my,dc=domain I have a local policy set.
> >
> > Should I set pwadmin in local policy level? global policy level is not
> enough?
>
> I think the ou policies over-ride the global policy, but regardless,
> password hash loading is a seperate issues - as mentioned a pre-hashed PW
> bypasses pwpolicy regardless of it's level, and is disallowed unless the
> above config value is set. It's not recommended to allow pre-hashed
> password upload in production long term, so as mentioned enable it, load
> the one password, then disable it.
>
>
>
> >
> > Thanks
> >
> > Alberto Viana
> >
> > On Tue, May 5, 2020 at 7:57 PM William Brown  wrote:
> >
> >
> > > On 6 May 2020, at 04:33, Alberto Viana  wrote:
> > >
> > > additional info: invalid password syntax - passwords with storage
> scheme are not allowed
> > >
> >
> >
> > This line here is saying that you have a userPassword: {SCHEME} in
> your ldif (I think). By default we don't allow this, but there is a migrate
> password hash option in cn=config.
> >
> > Of course, loading a hash this way bypasses the password policy checks
> 
> >
> > So you may want to check your ldif, and set the userPassword as
> cleartext for the modify, and the server-side will apply pwpolicy and
> perform proper hashing.
> >
> > Hope that helps,
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs
> > ___
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> > 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/389-users@lists.fedoraproject.org
> > ___
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> > 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/389-users@lists.fedoraproject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 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/389-users@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org

[389-users] Re: anonymous queries on second suffix subtrees

[William Brown]

> On 1 May 2020, at 00:56, Mc Laughlin David Bruce (ID BD) 
>  wrote:
> 
> Hi, Mark.
> 
> Your questions and comments have pointed me in the right direction and solved 
> several
> mysteries about missing db files, etc.
> 
> I will remove both root suffixes and their respective databases and then 
> re-create them using
> dscreate to create the instance and using dsconf (with the "--create-suffix" 
> option) to add the
>  second root suffix.

Yep, that would work. You can also consider just using dsconf to remove any 
suffixes you have currently and to just re-add them without needing to 
re-create the instance :) 

> 
> Even with the 
> https://directory.fedoraproject.org/docs/389ds/documentation.html site and the
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/  
> documentation,
> the product is so big that it is difficult to get an overview.

Yep, but that documentation is very helpful too :) 

> 
> I will not bother you again before the instance and its suffixes have been 
> rebuilt.

Feel free to bother us anytime, we are here to help!

> 
> Thanks for your help,
> David
> 
> ___
> David McLaughlin
> ETH Zürich / Swiss Federal Institute of Technology
> Informatikdienste
> Basisdienste
> Mail, Archive & Directories group
> CH-8092 Zürich
>  
> Tel.: +41 44 632 3531
> e-mail: david.mclaugh...@id.ethz.ch
> 
> 
> From: Mark Reynolds 
> Sent: 30 April 2020 4:21 PM
> To: Mc Laughlin David Bruce (ID BD); General discussion list for the 389 
> Directory server project.
> Subject: Re: [389-users] anonymous queries on second suffix subtrees
>  
> 
> On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:
>> Hi, Mark.
>> 
>> I did not expect a reply so soon!
>> 
>> When I query as "Directory Manager", I get the expected result.
>> 
>> I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.
> You should be using dscreate to create your instance, not setup-ds.pl
>> I used "dsconf backend create" to add the second suffix (o=psi,c=ch).
> Did you add any entries to o=psi,c=ch ?
>> 
>> The subtrees are not properly connected to their respective root suffixes.
>> Could this problem be caused by missing entries in the two "root suffix" 
>> databases?
>> 
>> [root@el-dap ~]#
>> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x -b 
>> 'o=psi,c=ch' '(ou=*)'
>> No such object (32)
> So you did not initialize this suffix.  It is empty.  
> When creating the backend you could have created the top database node entry 
> by adding the "--create-suffix" option:
> # dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch 
> --create-suffix
> Note - dscreate or dsconf do not add any aci's by default.  You have to add 
> the aci's after initializing the database with some data.
>> [root@el-dap ~]#
>> 
>> 
>> Anonymous queries  on the two subtrees (ou=staff & ou=student) on root 
>> suffix (o=ethz,c=ch) 
>> return the expected result.
> So searches on "ou=staff,o=ethz,c=ch" work?  But just searching on 
> "o=ethz,c=ch" does not?  I'm getting confused because you keep changing which 
> suffixes work or don't work.  First it was subtree's under o=psi,c=ch that 
> didn't return any results, now it's different subtrees under o=ethz,c=ch
> So if you are having issues with anything under "o=ethz,c=ch" then can you 
> please run this search, and also clarify which subtrees work and don't work 
> for anonymous searches under this suffix "o=ethz,c=ch":
> 
> # ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci
> Thanks,
> Mark
> 
>> 
>> However, anonymous queries on the o=ethz,c=ch root suffix  also return no 
>> records.
>> 
>> with best regards,
>> David
>> 
>> e-mail: david.mclaugh...@id.ethz.ch
>> 
>> 
>> From: Mark Reynolds 
>> Sent: 30 April 2020 3:10 PM
>> To: General discussion list for the 389 Directory server project.; Mc 
>> Laughlin David Bruce (ID BD)
>> Subject: Re: [389-users] anonymous queries on second suffix subtrees
>>  
>> 
>> On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
>>> Hello, 389ers.
>>> 
>>> I am migrating a whitepages server from OpenLDAP to 389-DS.
>>> 
>>> My instance has a root suffix with two subtrees (for staff and students).
>>> Anonymous queries of the two root suffix subtrees return the expected 
>>> results.
>>> 
>>> The instance also has a second suffix of "o=psi,c=ch" with three subtrees:
>>>   ou=contacts,o=psi,c=ch
>>>   ou=groups,o=psi,c=ch
>>>   ou=users,o=psi,c=ch
>>> 
>>> Anonymous queries of the three "o=psi,c=ch" subtrees return NO records.
>>> 
>>> I have added ACIs for the three "o=psi,c=ch" subtrees and restarted the 
>>> instance, but
>>> anonymous queries of any of the three "o=psi,c=ch" subtrees STILL return no 
>>> records.
>>> 
>>> Does anyone know how to allow anonymous queries?
>> First you don't need to restart the server when you add or change ACI's.  If 
>> you run the search as "cn=directory manager" does it return the results you 

[389-users] Re: pwadmin not working

[William Brown]

> On 6 May 2020, at 09:09, Alberto Viana  wrote:
> 
> William
> 
> I want to let this user bypass the policy and add a pre-hashed password,

If you want to add a pre-hashed password here, you'll need to change the 
password-migrate flag in cn=config, load that password, then unset the password 
migrate flag. 

https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/core_server_configuration_reference#nsslapd-allow-hashed-passwords



> I also have a global policy and some OU policies level. On this OU 
> OU=POP-PA,dc=my,dc=domain I have a local policy set.
> 
> Should I set pwadmin in local policy level? global policy level is not enough?

I think the ou policies over-ride the global policy, but regardless, password 
hash loading is a seperate issues - as mentioned a pre-hashed PW bypasses 
pwpolicy regardless of it's level, and is disallowed unless the above config 
value is set. It's not recommended to allow pre-hashed password upload in 
production long term, so as mentioned enable it, load the one password, then 
disable it.



> 
> Thanks
> 
> Alberto Viana
> 
> On Tue, May 5, 2020 at 7:57 PM William Brown  wrote:
> 
> 
> > On 6 May 2020, at 04:33, Alberto Viana  wrote:
> > 
> > additional info: invalid password syntax - passwords with storage scheme 
> > are not allowed
> > 
> 
> 
> This line here is saying that you have a userPassword: {SCHEME} in your 
> ldif (I think). By default we don't allow this, but there is a migrate 
> password hash option in cn=config.
> 
> Of course, loading a hash this way bypasses the password policy checks  
> 
> So you may want to check your ldif, and set the userPassword as cleartext for 
> the modify, and the server-side will apply pwpolicy and perform proper 
> hashing. 
> 
> Hope that helps,
> 
> —
> Sincerely,
> 
> William Brown
> 
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 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/389-users@lists.fedoraproject.org
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 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/389-users@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org

[389-users] Re: anonymous queries on second suffix subtrees

[Mc Laughlin David Bruce (ID BD)]

Hi, Mark.


Your questions and comments have pointed me in the right direction and solved 
several

mysteries about missing db files, etc.


I will remove both root suffixes and their respective databases and then 
re-create them using

dscreate to create the instance and using dsconf (with the "--create-suffix" 
option) to add the

 second root suffix.


Even with the https://directory.fedoraproject.org/docs/389ds/documentation.html 
site and the

https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/  
documentation,

the product is so big that it is difficult to get an overview.


I will not bother you again before the instance and its suffixes have been 
rebuilt.


Thanks for your help,

David

___
David McLaughlin
ETH Zürich / Swiss Federal Institute of Technology
Informatikdienste
Basisdienste
Mail, Archive & Directories group
CH-8092 Zürich

Tel.: +41 44 632 3531
e-mail: david.mclaugh...@id.ethz.ch



From: Mark Reynolds 
Sent: 30 April 2020 4:21 PM
To: Mc Laughlin David Bruce (ID BD); General discussion list for the 389 
Directory server project.
Subject: Re: [389-users] anonymous queries on second suffix subtrees



On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:

Hi, Mark.


I did not expect a reply so soon!


When I query as "Directory Manager", I get the expected result.


I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.

You should be using dscreate to create your instance, not setup-ds.pl

I used "dsconf backend create" to add the second suffix (o=psi,c=ch).

Did you add any entries to o=psi,c=ch ?


The subtrees are not properly connected to their respective root suffixes.

Could this problem be caused by missing entries in the two "root suffix" 
databases?


[root@el-dap ~]#
[root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x -b 
'o=psi,c=ch' '(ou=*)'
No such object (32)

So you did not initialize this suffix.  It is empty.

When creating the backend you could have created the top database node entry by 
adding the "--create-suffix" option:

# dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch --create-suffix

Note - dscreate or dsconf do not add any aci's by default.  You have to add the 
aci's after initializing the database with some data.

[root@el-dap ~]#



Anonymous queries  on the two subtrees (ou=staff & ou=student) on root suffix 
(o=ethz,c=ch)

return the expected result.

So searches on "ou=staff,o=ethz,c=ch" work?  But just searching on 
"o=ethz,c=ch" does not?  I'm getting confused because you keep changing which 
suffixes work or don't work.  First it was subtree's under o=psi,c=ch that 
didn't return any results, now it's different subtrees under o=ethz,c=ch

So if you are having issues with anything under "o=ethz,c=ch" then can you 
please run this search, and also clarify which subtrees work and don't work for 
anonymous searches under this suffix "o=ethz,c=ch":

# ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci

Thanks,
Mark



However, anonymous queries on the o=ethz,c=ch root suffix  also return no 
records.


with best regards,

David


e-mail: david.mclaugh...@id.ethz.ch



From: Mark Reynolds 
Sent: 30 April 2020 3:10 PM
To: General discussion list for the 389 Directory server project.; Mc Laughlin 
David Bruce (ID BD)
Subject: Re: [389-users] anonymous queries on second suffix subtrees



On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
Hello, 389ers.

I am migrating a whitepages server from OpenLDAP to 389-DS.

My instance has a root suffix with two subtrees (for staff and students).
Anonymous queries of the two root suffix subtrees return the expected results.

The instance also has a second suffix of "o=psi,c=ch" with three subtrees:
  ou=contacts,o=psi,c=ch
  ou=groups,o=psi,c=ch
  ou=users,o=psi,c=ch

Anonymous queries of the three "o=psi,c=ch" subtrees return NO records.

I have added ACIs for the three "o=psi,c=ch" subtrees and restarted the 
instance, but
anonymous queries of any of the three "o=psi,c=ch" subtrees STILL return no 
records.

Does anyone know how to allow anonymous queries?

First you don't need to restart the server when you add or change ACI's.  If 
you run the search as "cn=directory manager" does it return the results you 
expect?

Can you share all the ACI's you added to o=psi,c=ch subtrees?  Maybe gather all 
of them by using this search:

# ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch" aci=* aci

Thanks,
Mark


Thanks,
 David

[root@el-dap ~]#
[root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D "cn=Directory 
Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub '(aci=*)' aci
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (aci=*)
# requesting: aci
#
# users, 

[389-users] Re: pwadmin not working

[Mark Reynolds]

On 5/5/20 7:09 PM, Alberto Viana wrote:

William

I want to let this user bypass the policy and add a pre-hashed 
password, I also have a global policy and some OU policies level. On 
this OU OU=POP-PA,dc=my,dc=domain I have a local policy set.


Should I set pwadmin in local policy level? global policy level is not 
enough?
Global should be enough, sounds like a bug, but we haven't touched this 
code in a long time.  I need to see if I can reproduce it...


Thanks

Alberto Viana

On Tue, May 5, 2020 at 7:57 PM William Brown > wrote:




> On 6 May 2020, at 04:33, Alberto Viana mailto:alberto...@gmail.com>> wrote:
>
> additional info: invalid password syntax - passwords with
storage scheme are not allowed
>


This line here is saying that you have a userPassword:
{SCHEME} in your ldif (I think). By default we don't allow
this, but there is a migrate password hash option in cn=config.

Of course, loading a hash this way bypasses the password policy
checks 

So you may want to check your ldif, and set the userPassword as
cleartext for the modify, and the server-side will apply pwpolicy
and perform proper hashing.

Hope that helps,

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@lists.fedoraproject.org

To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org

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/389-users@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org

[389-users] Re: pwadmin not working

[Alberto Viana]

William

I want to let this user bypass the policy and add a pre-hashed password, I
also have a global policy and some OU policies level. On this OU
OU=POP-PA,dc=my,dc=domain I have a local policy set.

Should I set pwadmin in local policy level? global policy level is not
enough?

Thanks

Alberto Viana

On Tue, May 5, 2020 at 7:57 PM William Brown  wrote:

>
>
> > On 6 May 2020, at 04:33, Alberto Viana  wrote:
> >
> > additional info: invalid password syntax - passwords with storage scheme
> are not allowed
> >
>
>
> This line here is saying that you have a userPassword: {SCHEME} in
> your ldif (I think). By default we don't allow this, but there is a migrate
> password hash option in cn=config.
>
> Of course, loading a hash this way bypasses the password policy checks
> 
>
> So you may want to check your ldif, and set the userPassword as cleartext
> for the modify, and the server-side will apply pwpolicy and perform proper
> hashing.
>
> Hope that helps,
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 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/389-users@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org

[389-users] Re: pwadmin not working

[William Brown]

> On 6 May 2020, at 04:33, Alberto Viana  wrote:
> 
> additional info: invalid password syntax - passwords with storage scheme are 
> not allowed
> 


This line here is saying that you have a userPassword: {SCHEME} in your 
ldif (I think). By default we don't allow this, but there is a migrate password 
hash option in cn=config.

Of course, loading a hash this way bypasses the password policy checks  

So you may want to check your ldif, and set the userPassword as cleartext for 
the modify, and the server-side will apply pwpolicy and perform proper hashing. 

Hope that helps,

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org

[389-users] pwadmin not working

[Alberto Viana]

Hi Guys,
389 1.4.2.8

pwadmin is not working as expected:

dsconf RNP pwpolicy set --pwdadmin
cn=GRP_SRV_PREHASHED_PASSWORD,dc=my,dc=domain

In an specific OU, this user has the following permissions:
dn: OU=POP-PA,dc=my,dc=domain
aci: (targetattr="brPersonCPF || schacDateOfBirth || ntUserCreateNewAccount
||
  ntUserDeleteAccount || mail || objectClass || ntUserDomainId || cn ||
 given
 Name || sn || uid ||  ntUserDeleteAccount") (version 3.0;acl "All
attributes
 pop-pa Permissions";allow (add,write,read,search,compare,delete)
userdn="ldap
 :///uid=app.pop-pa.w,dc=my,dc=domain";)
aci: (targetattr="userPassword") (version 3.0;acl "userPassword attributes
pop
 -pa Permissions";allow (add,read,compare)
userdn="ldap:///uid=app.pop-pa.w,dc=my,dc=domain;;)

But I'm still getting the error:
ldapmodify -a -c -h localhost -D "uid=app.pop-pa.w,dc=my,dc=domain" -W -f
anderson.ldif

adding new entry "uid=anderson.souza,dc=my,dc=domain"
ldap_add: Constraint violation (19)
additional info: invalid password syntax - passwords with storage scheme
are not allowed

The user app.pop-pa.w is in GRP_SRV_PREHASHED_PASSWORD group.

Everything was working fine in my previous version of 389 with same config
(1.3.7.4)

Thanks
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org

[389-users] Re: DNA plugin not working

[Mark Reynolds]

You should be able to create different entries under:

|cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config ||dn: cn=UID 
numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config 
objectClass: top objectClass: extensibleObject cn: UID numbers 
dnatype: uidNumber dnamaxvalue: 1 dnamagicregen: 0 dnafilter: 
(objectclass=posixAccount) dnascope: dc=example,dc=com dnanextvalue: 500 dn: cn=GID 
numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config 
objectClass: top objectClass: extensibleObject cn: GID numbers dnatype: 
gidNumber dnamaxvalue: 1 dnamagicregen: 0 
dnafilter: (objectclass=posixGroup) dnascope: dc=example,dc=com 
dnanextvalue: 500|




On 5/5/20 1:57 PM, CHAMBERLAIN James wrote:
After a quick test, creating a second DNA entry under 
cn=plugins,cn=config was clearly not the way to go.  Adding it worked, 
but the test server refused to restart.  For any future reader who 
finds themselves in a similar situation, I got it back up and running 
again by removing that entry from /etc/dirsrv/slapd-/dse.ldif.


Best regards,

James

On May 5, 2020, at 12:45 PM, CHAMBERLAIN James 
mailto:james.chamberl...@3ds.com>> wrote:


Would adding the following create the second instance of DNA so I can 
manage UID and GID numbers separately, or am I overthinking this and 
it’s just a separate entry under cn=Distributed Numeric Assignment?


dn: cn=Distributed Numeric Assignment Plugin 2,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
objectClass: nsContainer
cn: Distributed Numeric Assignment Plugin 2
nsslapd-pluginInitfunc: dna_init
nsslapd-pluginType: bepreoperation
nsslapd-pluginEnabled: on
nsslapd-pluginPath: libdna-plugin
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: Distributed Numeric Assignment 2
nsslapd-pluginVersion: 1.3.7.5
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Distributed Numeric Assignment plugin

Thanks,

James


On Apr 30, 2020, at 2:25 PM, CHAMBERLAIN James 
mailto:james.chamberl...@3ds.com>> wrote:


Is it possible to create multiple instances of the DNA plugin on 
CentOS 7 / RHDS 10 / 389-ds-base-1.3.7.5-28.el7_5.x86_64?  The 
section on how to do this was added to the RHDS 11 documentation, 
and uses dsconf to do it.  If it is possible, could anyone 
comment on what dsconf is doing behind the scenes so I can replicate 
that?


Thanks,

James

On Apr 17, 2020, at 6:17 PM, Mark Reynolds > wrote:



On 4/17/20 5:19 PM, CHAMBERLAIN James wrote:

Hi all,

Thank you all for your help.  I’ve gotten DNA working.  I’ll be 
doing some further work to convince myself that I understand 
exactly what I did that got it working and can replicate it; but 
in the meantime, I had a question or two.


Do I correctly understand RHDS 11 Administration Guide, section 
7.4.3.1, to mean that if I want to have DNA manage uidNumber and 
gidNumber separately using different ranges, I’ll need to create 
two instances of the plugin?


I’m not finding dsconf on CentOS 7, including under “yum 
whatprovides ‘*/dsconf’”.  Am I missing something?  Was this tool 
released in something more recent than 1.3.7.5-28?


You need the RHDS 10 docs, only CentOS 8 has the new CLI tools 
(389-ds-base-1.4.x)


https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/

Sorry have to run, but I'll try and respond to your questions next 
week...




I suspect that the key differences between my original setup and 
what’s working now are the establishment of a dnaSharedCfgDN and 
non-overlapping initial ranges.  My original test setup was a 
single master server, which didn’t need these things.  It was 
suggested that I may need to include the attribute I wanted DNA to 
manage as part of creating an entry, and that I should give it 
dnaMagicRegen's value. However, this does not appear that it’s 
necessary - I was able to add a test user without specifying a 
uidNumber and DNA generated it for me.


Thanks,

James


On Apr 16, 2020, at 1:38 PM, CHAMBERLAIN James 
mailto:james.chamberl...@3ds.com>> wrote:


Hi Thierry,

The thing is, while this is on the production multi-master 
cluster, it’s not being used yet.  Any new entries being added 
have uidNumber set explicitly, except for my test entry.  I’ve 
been trying a few things and have a different error message now 
but the same result.  I’ll update the thread shortly with further 
details.


Best regards,

James


On Apr 16, 2020, at 1:23 PM, thierry bordaz > wrote:


Hi James,

I would guess that the allocated range is exhausted, means next 
value reached maxValue.

Possibly part of the range was taken by an other replica.

You can try to get more details with

ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-accesslog-level
nsslapd-acceslog-level: 260 (default level 256 plus 4 for 
internal operations)

-
replace: nsslapd-plugin-logging

[389-users] Re: DNA plugin not working

[CHAMBERLAIN James]

Would adding the following create the second instance of DNA so I can manage 
UID and GID numbers separately, or am I overthinking this and it’s just a 
separate entry under cn=Distributed Numeric Assignment?

dn: cn=Distributed Numeric Assignment Plugin 2,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
objectClass: nsContainer
cn: Distributed Numeric Assignment Plugin 2
nsslapd-pluginInitfunc: dna_init
nsslapd-pluginType: bepreoperation
nsslapd-pluginEnabled: on
nsslapd-pluginPath: libdna-plugin
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: Distributed Numeric Assignment 2
nsslapd-pluginVersion: 1.3.7.5
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Distributed Numeric Assignment plugin

Thanks,

James


On Apr 30, 2020, at 2:25 PM, CHAMBERLAIN James 
mailto:james.chamberl...@3ds.com>> wrote:

Is it possible to create multiple instances of the DNA plugin on CentOS 7 / 
RHDS 10 / 389-ds-base-1.3.7.5-28.el7_5.x86_64?  The section on how to do this 
was added to the RHDS 11 documentation, and uses dsconf to do it.  If it is 
possible, could anyone comment on what dsconf is doing behind the scenes so I 
can replicate that?

Thanks,

James

On Apr 17, 2020, at 6:17 PM, Mark Reynolds 
mailto:mreyno...@redhat.com>> wrote:


On 4/17/20 5:19 PM, CHAMBERLAIN James wrote:
Hi all,

Thank you all for your help.  I’ve gotten DNA working.  I’ll be doing some 
further work to convince myself that I understand exactly what I did that got 
it working and can replicate it; but in the meantime, I had a question or two.

Do I correctly understand RHDS 11 Administration Guide, section 7.4.3.1, to 
mean that if I want to have DNA manage uidNumber and gidNumber separately using 
different ranges, I’ll need to create two instances of the plugin?

I’m not finding dsconf on CentOS 7, including under “yum whatprovides 
‘*/dsconf’”.  Am I missing something?  Was this tool released in something more 
recent than 1.3.7.5-28?

You need the RHDS 10 docs, only CentOS 8 has the new CLI tools 
(389-ds-base-1.4.x)

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/

Sorry have to run, but I'll try and respond to your questions next week...


I suspect that the key differences between my original setup and what’s working 
now are the establishment of a dnaSharedCfgDN and non-overlapping initial 
ranges.  My original test setup was a single master server, which didn’t need 
these things.  It was suggested that I may need to include the attribute I 
wanted DNA to manage as part of creating an entry, and that I should give it 
dnaMagicRegen's value. However, this does not appear that it’s necessary - I 
was able to add a test user without specifying a uidNumber and DNA generated it 
for me.

Thanks,

James


On Apr 16, 2020, at 1:38 PM, CHAMBERLAIN James 
mailto:james.chamberl...@3ds.com>> wrote:

Hi Thierry,

The thing is, while this is on the production multi-master cluster, it’s not 
being used yet.  Any new entries being added have uidNumber set explicitly, 
except for my test entry.  I’ve been trying a few things and have a different 
error message now but the same result.  I’ll update the thread shortly with 
further details.

Best regards,

James


On Apr 16, 2020, at 1:23 PM, thierry bordaz 
mailto:tbor...@redhat.com>> wrote:

Hi James,

I would guess that the allocated range is exhausted, means next value reached 
maxValue.
Possibly part of the range was taken by an other replica.

You can try to get more details with

ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-accesslog-level
nsslapd-acceslog-level: 260   (default level 256 plus 4 for internal 
operations)
-
replace: nsslapd-plugin-logging
nsslapd-plugin-logging: on

and lookup at the entry ldapsearch -D DM... -b "cn=UID numbers,cn=Distributed 
Numeric Assignment Plugin,cn=plugins,cn=config" -s base nscpentrywsi


best regards
thierry
On 4/13/20 8:41 PM, CHAMBERLAIN James wrote:
Hi Mark,

Thanks for getting back to me.  After adjusting nsslapd-errorlog-level, here’s 
what I’ve got.

# grep dna-plugin /var/log/dirsrv/slapd-example/errors
[13/Apr/2020:14:30:00.480608036 -0400] - DEBUG - dna-plugin - _dna_pre_op_add - 
dn does not match filter
[13/Apr/2020:14:30:00.486700059 -0400] - DEBUG - dna-plugin - _dna_pre_op_add - 
adding uidNumber to uid=testuser1,ou=People,dc=example,dc=com as -2
[13/Apr/2020:14:30:00.559245389 -0400] - DEBUG - dna-plugin - _dna_pre_op_add - 
retrieved value 0 ret 1
[13/Apr/2020:14:30:00.561303217 -0400] - ERR - dna-plugin - _dna_pre_op_add - 
Failed to allocate a new ID!! 2
[13/Apr/2020:14:30:00.571360868 -0400] - DEBUG - dna-plugin - dna_pre_op - 
Operation failure [1]

And here’s the DNA config:

dn: cn=UID numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: UID numbers
dnaType: uidNumber
dnamaxvalue: 10
dnamagicregen: 0
dnafilter: