[389-users](re)enabling a password policy
Hello, Looking for some guidance with password policies. About a year ago I migrated a very old instance of Red Hat Directory server to 389-ds version 1.3.5.10. I did this with a db export and import. I did not enable the password policy which was active on the old Red Hat Directory instance. It has come time to (re)enable a password policy on the 389-ds instance and I am hoping for some guidance on how to proceed. The policy would be one of syntax and expiration requirements. All the applicable users appear to have the require attributes (passwordexpirationtime, passwordexpwarned, passwordgracetimeuser, passwordhistory, passwordretrycount, retrycoutresettime) Questions: 1. All the users on which the password policy should apply are under ou=People,dc=sub,dc=domain,dc=tld o It should therefore be safe to apply the password policy here for subtree? 2. What is the best way to set individual users who should be exempt from the policy? 3. Some of the users who should be exempt are within nsPwPolicyContainer under ou=People. Does this relate to question #2? 4. Given that there has been a long time passed where the password policy has not been active, it probably makes sense to set applicable user’s passwordexpirationtime attribute to sometime in the future so there isn’t a flood of “password lockout” complaints? [cid:EL-logo_7ba48a57-966c-4a07-b478-7857c99d9581.png] Kirk MacDonald | System Analyst II Eastlink | Internet kirk.macdon...@corp.eastlink.caT: 902.406.4969 ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] LDAP: error code 19 - invalid password syntax - passwords with storage scheme are not allowed
Hello I am migrating an LDAP system from CentOS-Directory/8.1.0 B2009.134.1334 to 389-Directory/1.3.5.10 B2017.145.2037 We have an external app/too for user password management. The tool binds as a special user when changing passwords in the "forgot password" use case, and as the regular user in the "I know my password but want to change it" use case. In both use cases the tool has the behavior of generating an SSHA hash string and then doing an ldapmodify to change the userPassword value to that string. When we tested the tool against the new instances we got the error in the subject. I had already defined the proper ACI for the special user. Digging around I found if I provided the dn for special user in the passwordAdminDN attribute value in cn=config the "forgot password" use case worked. However the application will of course continue to fail when it binds as the regular users. One additional item - the systems we are coming from do have a Password Policy configured, but I have not explicitly configured one yet on the new systems, even though the relevant per-user attributes came over in the db migration. However, the password policy is only for when the passwords need to be changed/expired, as opposed to syntax/strength. Is there a way around this without changing our app/tool to send the plain password over SSL/TLS/STARTTLS? Thanks Kirk MacDonald Eastlink ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Re: Registering remote 389-DS instances in Console
I would suggest adding something above the screenshot which shows the properly configured 2 server 1 admin console scenario. Perhaps simply a walkthrough of register-ds-admin.pl when invoked interactively, for the relatively simple use case I was trying to execute. What tripped me up was the point, highlighted in red. I was expecting to be able to enter an LDAP URI: ldap://host.domain:389/o=NetscapeRoot since I was looking to register a remote server. The reality is that the script is basically asking what Configuration Directory Server are you going to Register INTO, before what remote server do you want to register. Since the script probably can’t tell you that the local instance has/has not already been registered in the local Configuration Directory Server (which is what I thought this script would ONLY accomplish, initially), some more details in the documentation at the URL you mention would have helped me. # register-ds-admin.pl Beginning registration of the Directory Server == The Directory Server locates its configuration file (dse.ldif) at /etc/dirsrv/slapd-ID, by default. If you have Directory Server(s) which configuration file is put at the other location, you need to input it to register the server. If you have such Directory Server, type the full path that stores the configuration file. If you don't, type return. [configuration directory path or return]: == Do you want to use this server as Configuration Directory Server? Directory server identifier []: == Registering new Config DS: == Input the Directory Manager password on the server ldap1: == Please input the password for the Administrator User uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot: == Beginning Admin Server reconfiguration . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Restarting admin server . . . The admin server was successfully started. Admin server was successfully reconfigured and started. == Do you want to register a remote server with the local configuration server (y/n)? y - Kirk From: Mark Reynolds [mailto:marey...@redhat.com] Sent: Thursday, August 24, 2017 4:04 PM To: Kirk MacDonald <kirk.macdon...@corp.eastlink.ca>; General discussion list for the 389 Directory server project. <389-users@lists.fedoraproject.org> Subject: Re: [389-users] Re: Registering remote 389-DS instances in Console On 08/24/2017 02:31 PM, Kirk MacDonald wrote: OK scratch that – it of course does work interactively. I was just being thrown off by the fact one has to (re)config/specify the local Admin instance each time. Later on in the interactive it asks for the remote hosts. Silly me. Hi Kirk, Glad you got it working. Regarding: http://www.port389.org/docs/389ds/design/console-remote-reg-design.html , what can improved here? Better docs on the "interactive" mode, or INF file mode? Thanks, Mark -Kirk From: Kirk MacDonald [mailto:kirk.macdon...@corp.eastlink.ca] Sent: Thursday, August 24, 2017 1:36 PM To: Mark Reynolds <marey...@redhat.com><mailto:marey...@redhat.com>; General discussion list for the 389 Directory server project. <389-users@lists.fedoraproject.org><mailto:389-users@lists.fedoraproject.org> Subject: [389-users] Re: Registering remote 389-DS instances in Console Thanks for the reply. I am struggling with the script because it only seems to see local instances, when running the script interactively. - Kirk From: Mark Reynolds Sent: Thursday, August 24, 2017 1:30 PM To: General discussion list for the 389 Directory server project.; Kirk MacDonald Subject: Re: [389-users] Registering remote 389-DS instances in Console On 08/24/2017 11:30 AM, Kirk MacDonald wrote: I have built 3 new 389-DS instances (389-Directory/1.3.5.10 B2017.145.2037) on different services. Each has local Admin console. They are all in the same Administrative Domain. Perfect... Is the method to register the remote instances in each local Admin console what is described here: http://www.port389.org/docs/389ds/design/console-remote-reg-design.html ? Are you planning on using one central Admin/Config server? If so, you just need to registers
[389-users] Re: Registering remote 389-DS instances in Console
OK scratch that – it of course does work interactively. I was just being thrown off by the fact one has to (re)config/specify the local Admin instance each time. Later on in the interactive it asks for the remote hosts. Silly me. -Kirk From: Kirk MacDonald [mailto:kirk.macdon...@corp.eastlink.ca] Sent: Thursday, August 24, 2017 1:36 PM To: Mark Reynolds <marey...@redhat.com>; General discussion list for the 389 Directory server project. <389-users@lists.fedoraproject.org> Subject: [389-users] Re: Registering remote 389-DS instances in Console Thanks for the reply. I am struggling with the script because it only seems to see local instances, when running the script interactively. - Kirk From: Mark Reynolds Sent: Thursday, August 24, 2017 1:30 PM To: General discussion list for the 389 Directory server project.; Kirk MacDonald Subject: Re: [389-users] Registering remote 389-DS instances in Console On 08/24/2017 11:30 AM, Kirk MacDonald wrote: I have built 3 new 389-DS instances (389-Directory/1.3.5.10 B2017.145.2037) on different services. Each has local Admin console. They are all in the same Administrative Domain. Perfect... Is the method to register the remote instances in each local Admin console what is described here: http://www.port389.org/docs/389ds/design/console-remote-reg-design.html ? Are you planning on using one central Admin/Config server? If so, you just need to registers the other 3 remote servers with your local one. Done. If want to goto any admin server and see all the other servers then you have to do the same thing on each host: Goto Server A, and register B, C, D, goto Server B - register A, C, D, etc, etc. Or, is there a more “simplistic” approach that can be done via each Admin console UI? Using the script is the easiest. There is no way to do it via the console ui. Regards, Mark Thanks, Kirk MacDonald Eastlink ___ 389-users mailing list -- 389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org<mailto:389-users-le...@lists.fedoraproject.org> ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Re: Registering remote 389-DS instances in Console
Thanks for the reply. I am struggling with the script because it only seems to see local instances, when running the script interactively. - Kirk From: Mark Reynolds Sent: Thursday, August 24, 2017 1:30 PM To: General discussion list for the 389 Directory server project.; Kirk MacDonald Subject: Re: [389-users] Registering remote 389-DS instances in Console On 08/24/2017 11:30 AM, Kirk MacDonald wrote: I have built 3 new 389-DS instances (389-Directory/1.3.5.10 B2017.145.2037) on different services. Each has local Admin console. They are all in the same Administrative Domain. Perfect... Is the method to register the remote instances in each local Admin console what is described here: http://www.port389.org/docs/389ds/design/console-remote-reg-design.html ? Are you planning on using one central Admin/Config server? If so, you just need to registers the other 3 remote servers with your local one. Done. If want to goto any admin server and see all the other servers then you have to do the same thing on each host: Goto Server A, and register B, C, D, goto Server B - register A, C, D, etc, etc. Or, is there a more “simplistic” approach that can be done via each Admin console UI? Using the script is the easiest. There is no way to do it via the console ui. Regards, Mark Thanks, Kirk MacDonald Eastlink ___ 389-users mailing list -- 389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org<mailto:389-users-le...@lists.fedoraproject.org> ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] Registering remote 389-DS instances in Console
I have built 3 new 389-DS instances (389-Directory/1.3.5.10 B2017.145.2037) on different services. Each has local Admin console. They are all in the same Administrative Domain. Is the method to register the remote instances in each local Admin console what is described here: http://www.port389.org/docs/389ds/design/console-remote-reg-design.html ? Or, is there a more “simplistic” approach that can be done via each Admin console UI? Thanks, Kirk MacDonald Eastlink ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] CentOS-Directory/8.1.0 B2009.134.1334 ldapsearch problem
Hello, I'm working on migrating from CentOS-Directory/8.1.0 B2009.134.1334 to 389-Directory/1.3.5.10 B2017.145.2037. What I'm finding is that the Database Export functions in the CentOS-Directory/8.1.0 B2009.134.1334 Console as well as ldapsearches aren't returning all entries. Specifically an objectclass=* search filter for a given ou fails to output all entries. However if the search filter is for an attribute which exists, all applicable entries are returned. The Console also does not show entries that might otherwise be found with a ldapsearch and a specific search filter. Based on some experience I have with another LDAP system this feels like an ancestorid problem. Can anyone offer any tips/thoughts or questions to clarify my problem? Thank you Kirk MacDonald ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
