August 2019 - 389-users - Fedora mailing-lists

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

Hi, I'm new to 389-ds and last week downloaded and installed the software. I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query the server using TLS/SSL, and all appears working. I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client can see the unix users and groups using the "getent password" or "getent group" commands. Now, here's where I'm getting tripped up.......... I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations. I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-groups…) which is close enough to CentOS that the initial commands worked. I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system. I created a test group (that I didn't enable a posix GID) and tried to add a single user via: Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add. When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error: "Cannot save to directory server. netscape.ldap.LDAPException: error resiult(65): Object class violation" And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors: "Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed [17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)" So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before I even try to filter login access via groups on my client system. I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I should set the "value" to be. I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute on individual users, only groups. This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions. Any suggestions would be appreciated.

6 19

Re: FIPS 140-2 and dirsrv-admin
by William Brown 13 Sep '19

13 Sep '19

If memory serves correctly ... there are some un-resolved issues between dirsrv-admin + fips. I remember discussing this with Mark as something that may fall into the "fix when someone runs into it" because that combination we thought would be rare. But I'm not sure that this issue here is a fips one? I've seen another issue lately where the dirsrv-admin used a different pin.txt to the dirsrvinstances, but I'm not sure of the details. Are there fresh installs of ds? Or upgrades? > On 28 Aug 2019, at 05:51, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > Hi guys, > > I have SSL enabled both slapd instances and dirsrv-admin on FIPS enabled CentOS 7. The instances seem to start up no problem. However, the admin console (dirsrv-admin) is complaining the password credentials are not valid for the NSS FIPS 140-2 DB even through the exact same credentials are presented to the SLAPD instances. I am using a pin.txt file in the correct format for both SLAPD and DIRSRV-ADMIN. > > Are there compatibility issues with FIPS and 389-DS admin-serv? > > Paul M. Whitney > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)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… — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

4 12

BIND (DNS)
by Fernando Fuentes 04 Sep '19

04 Sep '19

Is there a plugin or a default schema for BIND (named) on Fedora389? Or do I have to import the included schema with bind9? Thanks! Regards, -

2 10

Windows Sync Agreement issue
by DaV 04 Sep '19

04 Sep '19

Hi all, I'm using a new 389 directory server on CentOS 7.6 with 389-ds-base.x86_64 (1.3.8.4-15.el7), and I want to sync user and password from Windows 2016 to 389ds one way. The Synchronization Agreement like this: DS Host: 389ds:389 Windows Host: dc01.example.com:389 DS Subtree: ou=Users,dc=example,dc=com Windows Subtree: OU=Accounts, DC=example,DC=com Replicated subtree: dc=example,dc=com Here is my question: The sync agreement can only sync top-level OU=Accounts, DC=example, DC=com from Win2016 to 389ds server. In fact, I have ou=ou1,ou=accounts,dc=example,dc=com ou=ou2,ou=accounts,dc=example,dc=com on Win2016 server. I want the sync agreement can sync not only the top-level but also the child ou. This is the error log for your reference. Thanks! > [20/Aug/2019:07:58:40.307031692 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)". > [20/Aug/2019:07:58:40.309113230 +0800] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests > [20/Aug/2019:08:34:21.730939271 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:21.733526550 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:24.735819391 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:27.738228528 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:30.873896680 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)". > [20/Aug/2019:08:34:33.170822223 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries. > [20/Aug/2019:08:34:33.186359842 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds" (tc-dc-2:389): Replication bind with SIMPLE auth resumed > [20/Aug/2019:08:47:30.032935119 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)". > [20/Aug/2019:08:47:31.035850854 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries. > [20/Aug/2019:08:47:31.051614890 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds" (tc-dc-2:389): Replication bind with SIMPLE auth resumed > [20/Aug/2019:08:50:59.533268105 +0800] - WARN - NSMMReplicationPlugin - prot_stop - Incremental protocol for replica "agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly. > [20/Aug/2019:09:01:00.155477769 +0800] - WARN - NSMMReplicationPlugin - prot_stop - Total protocol for replica "agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly. Sincerely, -- DaV

4 15

Adding fields for "NT" and "Posix" User to the web gui gateway interface
by Janet Houser 30 Aug '19

30 Aug '19

Hi Folks, I've just started to play with the "Directory Server Gateway" options to add users and groups. One think I've noticed is that the default user form doesn't have a way to enable "NT User" or "Posix User" attributes or the ability to add info for the supporting fields (e.g. uid, gid, home directory, etc.). I've been looking at the following fedoraproject pages: https://directory.fedoraproject.org/docs/389ds/administration/dsgw.html and https://directory.fedoraproject.org/docs/389ds/administration/webapps-insta… But I can't seem to find a place where it tells me how to add these options to the page via the dsgw.conf or pb.conf files. Can you point me to some resources that might help me understand how to add these options to the ds-389 web portal? Thanks, j

3 3

Blog series about 389 DS + thanks
by Nicolas Kovacs 30 Aug '19

30 Aug '19

Hi, Over the last couple of weeks, I've experimented quite a lot with 389 Directory Server. I've had good help on this list, so I wanted to thank you guys. I've started to write a series of blog articles about 389 DS, and I've added two honorable mentions for Marc Muehlfeld and William Brown, who have provided precious information. https://www.microlinux.fr/389-ds-centos-7/ Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

2 1

FIPS 140-2 and dirsrv-admin
by Paul Whitney 27 Aug '19

27 Aug '19

Hi guys, I have SSL enabled both slapd instances and dirsrv-admin on FIPS enabled CentOS 7. The instances seem to start up no problem. However, the admin console (dirsrv-admin) is complaining the password credentials are not valid for the NSS FIPS 140-2 DB even through the exact same credentials are presented to the SLAPD instances. I am using a pin.txt file in the correct format for both SLAPD and DIRSRV-ADMIN. Are there compatibility issues with FIPS and 389-DS admin-serv? Paul M. Whitney

1 0

LDAp password error
by Fernando Fuentes 27 Aug '19

27 Aug '19

Hello All, I am using a web ui to add end delete users. When I reset or try to add a password I get: LDAP error, server says: Constraint violation - invalid password syntax - passwords with storage scheme are not allowed What do I need to turn on to be able to use the web ui to edit passwords? Thanks again! (Using LAM web ui) Regards.

2 2

Setup a Linux client for authentication against 389 DS + TLS
by Nicolas Kovacs 26 Aug '19

26 Aug '19

Hi, So I finally managed to get a 389 Directory Server up and running on a spare CentOS 7 server. I can open the console even on a remote desktop (using ssh -X), connect to my LDAP database, create a handful of users, and I even managed to setup TLS. The next step is getting a Linux client to authenticate using the credentials stored on my servers. Normally I'm running OpenSUSE Leap 15.1 KDE on all my desktop clients, but for the sake of experimenting, information about any distribution is welcome. So far I've been using a bone-headed NIS/NFS setup, which I intend to replace with 389 DS and secure connections. I tried to connect my OpenSUSE clients to my 389 DS where I had the odd fleeting success and many failures. You know that feeling when you spent a whole weekend on a configuration and things still don't work? I'd like to get a firm grasp on how to connect my Linux clients to the 389 DS. So ideally I'd be glad to find some detailed documentation about that. Even if it's based on a different distribution. Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

2 1

Re: A bit help about ACI?
by William Brown 26 Aug '19

26 Aug '19

> On 26 Aug 2019, at 17:36, Miljan Žugić <Miljan.Zugic(a)halcom.rs> wrote: > > First, i really wanna say big thanks for super fast answer. Above all, concise and technical, concrete with facts.. > Second, i did home work and read it link (which i did before also, but..maybe i miss something 😊 and read again) > Third, i already did what you write: deny on specific lvl for anonymous (anyone), and allow (whatever) for specific user..But this dosnt work. Looks "deny" is stronger..which is strange for me, your explanation sound perfectly fine. > Is it possible to get functionality on 389DS like targetbase = sub, onelevel, base..? > Forth, " using onelevel rules or labeling with filters instead" sound really great. Where i can get some example of this? Deny is "stronger" yes, but it has interactions that may be "unforseen". It's better to say "you have allow to these limited things" than "you are allowed to lots and we deny little bits we don't want". The deny way leaves room for mistakes if you add a subtree later and forget the deny, or the deny could be too broad, etc. https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ The documentation here is what is used by Directory Server. Mark already linked the access control chapter. In that section have a look at: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… You can use this rule on ou=people for example dn: ou=People,dc=example,dc=com ou: People aci: (target = "ldap:///uid=*,ou=people,dc=example,dc=com")(targetattr = "uid || cn || displayname")(version 3.0; acl "example"; allow (read, search, compare)(userdn = "ldap:///anyone");) This would allow "anonymous" and all other accounts to read uid, cn and displayname, where the rdn starts with "uid=" under ou=people. Does that help? It's always a good idea to try these things out of course :) > > And you don’t need to answer. I'm already happy, because i work with Apache ldap till now and ... always some strange behavior and 0 help..and yes, on site on advanced features you can read only " TO DO ...".. We are always happy to answer, and we hope that we can help you to learn and make your LDAP install be the best possible. If you have any other questions or comments, please always contact us! > > Really Best Regards and have nice day! > > > > Miljan Žugić > Sistemski inženjer | Systems engineer > Sistemska podrška | Corporate IT > > T +381 11 3306514 > M +381 62 250 523 > E Miljan.Zugic(a)halcom.rs > > Halcom a.d. > Beogradska 39 | 11000 Beograd | Srbija > > www.halcom.rs > -----Original Message----- > From: William Brown <wbrown(a)suse.de> > Sent: Monday, August 26, 2019 1:09 AM > To: 389-users(a)lists.fedoraproject.org > Cc: Miljan Žugić <Miljan.Zugic(a)halcom.rs> > Subject: Re: [389-users] Re: A bit help about ACI? > > > >> On 24 Aug 2019, at 01:48, Mark Reynolds <mreynolds(a)redhat.com> wrote: >> >> >> On 8/23/19 11:34 AM, Mark Reynolds wrote: >>> Moving to the correct list (389-users)... >>> >>> On 8/23/19 9:05 AM, Miljan Žugić wrote: >>>> I apologize in advance if this is wrong address 😊 >>>> I build up 2 389 DS server, make replication and up till now, all looks fine. >>>> But I have some issue about ACI. Where I can find good forum or site to get some real examples of ACI ? >>>> >>>> Or if you can help me…I want something like this, to make “anonymous” can do read, search and compare for levels B and D, but deny to A and E (actually I have problem with level E, I can do deny to anyone to level E or deeper, but I need some specific accounts to access level E or deeper, so…I stuck how to do that) : >> First you should really read the access control docs: >> >> https://access.redhat.com/documentation/en-us/red_hat_directory_server >> /10/html/administration_guide/managing_access_control >> >> In order to do what you want you need two kinds of aci, allow and deny. You need deny rules because when you set an aci on a subtree it applies to all its children. So as you noted you can deny level E, but it denies everyone even if they previously had access. So you need to add new aci's on level E that open up access to the users/groups you want to have access. So you might end up with "duplicate" aci's at different levels in your tree. >> >> So on level B you have your anonymous access aci's - this will apply to all lower branches. On Level E must have a deny "anonymous/anyone" rule, and then you add new acis to level E that open it back up for those you want to have access. > > Another way to tackle this is a costemplate that adds a security label to the "onelevels" you want accessible, then have an allow anonymous rule to filter on the security label that is added. Of course, you need to ensure people can't write that label type ... > > Deny rules always make aci's messy - they really do make it confusing to audit and "see" what's going on. > > So I think here, you should probably reconsider your tree layout and if it's the correct structure, or consider using onelevel rules or labeling with filters instead, to keep it to "allow only" rules. > >> >> HTH, >> >> Mark >> >> >> >>>> >>>> <image003.png> >>>> >>>> Anyhow, BR 😃 >>>> >>>> >>>> Miljan Žugić >>>> Sistemski inženjer | Systems engineer >>>> Sistemska podrška | Corporate IT >>>> >>>> T +381 11 3306514 >>>> M +381 62 250 523 >>>> E Miljan.Zugic(a)halcom.rs >>>> >>>> >>>> >>>> >>>> >>>> Halcom a.d. >>>> Beogradska 39 | 11000 Beograd | Srbija >>>> >>>> www.halcom.rs >>>> >>>> >>> -- >>> >>> 389 Directory Server Development Team >>> >>> >>> >>> _______________________________________________ >>> 389-users mailing list -- >>> 389-users(a)lists.fedoraproject.org >>> >>> To unsubscribe send an email to >>> 389-users-leave(a)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.fedorap >>> roject.org >> -- >> >> 389 Directory Server Development Team >> >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)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.fedorapr >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

1 0

Test LDAP client connection
by Nicolas Kovacs 26 Aug '19

26 Aug '19

Hi, So it looks like my 389 DS server is running. I admit I'm fighting every step to get this thing to run. As it looks, the next step is to test the LDAP client connection. Which leads me to my first question. When TLS is enabled, is it still possible to get plain (e. g. unencrypted) connections from a client? What commands do you use on a Linux client to test basic LDAP connection, plain and/or secure? Thanks & Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

2 1

Using self-signed SSL certificate with 389 DS under CentOS 7
by Nicolas Kovacs 26 Aug '19

26 Aug '19

Hi, I've spent a couple hours trying to install a self-signed SSL certificate in my 389 DS installation running CentOS 7. The method using the command-line (specified in the RHDS 10 Administration Guide in Chapter 9) doesn't work. Neither do any of the various HOWTOs and blogs scattered over the web. So before I go any further. Is there any *working* method to get a self-signed SSL certificate installed in 389 DS? Any pointers to a no-nonsense documentation that actually works with my installed version of 389-DS and doesn't require me to jump through burning loops ? Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

3 8

Re: A bit help about ACI?
by Mark Reynolds 25 Aug '19

25 Aug '19

Moving to the correct list (389-users)... On 8/23/19 9:05 AM, Miljan Žugić wrote: > > I apologize in advance if this is wrong address 😊 > > I build up 2 389 DS server, make replication and up till now, all > looks fine. > > But I have some issue about ACI. Where I can find good forum or site > to get some real examples of ACI ? > > Or if you can help me…I want something like this, to make “anonymous” > can do read, search and compare for levels B and D, but deny to A and > E (actually I have problem with level E, I can do deny to anyone to > level E or deeper, but I need some specific accounts to access level E > or deeper, so…I stuck how to do that) : > > Anyhow, BR 😃 > > *Miljan Žugić* > > Sistemski inženjer | Systems engineer > > Sistemska podrška**| Corporate IT > > ** > > *T* +381 11 3306514 > > *M*+381 62 250 523 > > *E* Miljan.Zugic(a)halcom.rs > > *Halcom a.d.* > > Beogradska 39 | 11000 Beograd | Srbija > > *www.halcom.rs* > -- 389 Directory Server Development Team

2 2

389ds automount issue
by DaV 23 Aug '19

23 Aug '19

Hi all, First of all, I don't know whether if this is a bug and I don't know where to submit a bug. My 389ds info: OS: CentOS Linux release 7.6.1810 (Core) 389ds: 389-ds-base-1.3.8.4-15.el7.x86_64 On 389ds server, I have configured like this > # auto.master, service, example.com > dn: nismapname=auto.master,ou=service,dc=example,dc=com > nisMapName: auto.master > objectClass: nisMap > objectClass: top > > # /home, auto.master, service, example.com > dn: cn=/home,nismapname=auto.master,ou=service,dc=example,dc=com > nisMapName: home > objectClass: nisObject > objectClass: top > cn: /home > nisMapEntry: ldap 389ds.example.com > > # *, auto.home, service, example.com > dn: cn=*,nismapname=auto.home,ou=service,dc=example,dc=com > nisMapName: home > nisMapEntry: -fstype=nfs4,defaults,_netdev,acl sun:/home/& > objectClass: nisObject > objectClass: top > cn: *:nismapname=auto.home,ou=service,dc=example,dc=com > On client side When I want to change directory under home (cd /home/username), I can't. So I enable the autofs debug mode, and I see some message like this > Aug 22 15:55:36 centos automount[2424]: parse_server_string: lookup(ldap): server "ldap://ds.example.com/", base dn "nismapname=auto.home,ou=service,dc=example,dc=com" The prefix 389 has gone. The client says can't connect LDAP server because in 389ds server I write ldap 389ds.example.com but I see ds.example.com on client-side. I don't know whether this is a bug. Just write this to let you know. Thanks! My solution is: change the 389ds server-side using nisMapEntry: ldap tc-389ds.example.com. Sincerely, -- DaV

2 10

New SSL
by Fernando Fuentes 22 Aug '19

22 Aug '19

After getting everything working I was able to enable SSL on the console. But now the console is unable to start with the error: [Thu Aug 22 15:15:35.680397 2019] [:error] [pid 25091:tid 139708987033728] Password for slot internal is incorrect. [Thu Aug 22 15:15:35.680824 2019] [:error] [pid 25091:tid 139708987033728] NSS initialization failed. Certificate database: /etc/dirsrv/admin-serv. [Thu Aug 22 15:15:35.680841 2019] [:error] [pid 25091:tid 139708987033728] SSL Library Error: -8177 The security password entered is incorrect What password is this talking about? All of the password entered are correct... I am confused... :(

2 13

SSL on console
by Fernando Fuentes 22 Aug '19

22 Aug '19

Hello all. I have configured SSL to my dirsrv and works just fine but when I try to configure the ssl portion for the console, Under Admin Server -> Encryption... I cant find my CA there. How can import it for the Admin console? Using Fedore389 Admin Server 1.1.46 TIA!

3 9

Place to put lessons learned?
by Chris Motta 20 Aug '19

20 Aug '19

We have a new install of 389 Directory server, and have all of our CentOS 7 hosts authenticating to it. After fiddling with some knobs for our Palo Alto Networks and GitLab installations, we are success- fully using the 389-DS server for single sign-on. Those settings might be useful for others who are using a Palo Alto Networks device and/or GitLab. Most of the examples for using LDAP for those apps seem to have a lot for AD LDAP, and not 389-DS. Where is the best place to post lessons learned from setting up those configurations? Thanks- jcm -- JC Motta (jcm) IT Consultant Apex Semi cmotta(a)apexsemi.com 408-805-0245 -- Confidential and Proprietary Communication of Apex Semiconductor Inc. If you are not the intended recipient, any dissemination, distribution or copying this communication is prohibited. If you think that you have received this email message in error, please email the sender.

2 1

issue with fresh install of directory server
by Chase Miller 20 Aug '19

20 Aug '19

Hello, I have a fresh install of Centos 7. (this is not my first install of Directory Server, btw) Followed this article: https://webhostinggeeks.com/howto/setup-389-directory-server-on-centos-7/ cat setupV6AAJP.log [19/08/19:08:49:28] - [Setup] Info This program will set up the 389 Directory and Administration Servers. It is recommended that you have "root" privilege to set up the software. Tips for using this program: - Press "Enter" to choose the default and go to the next screen - Type "Control-B" then "Enter" to go back to the previous screen - Type "Control-C" to cancel the setup program [19/08/19:08:49:28] - [Setup] Info Would you like to continue with set up? [19/08/19:08:49:31] - [Setup] Info yes [19/08/19:08:49:31] - [Setup] Info Your system has been scanned for potential problems, missing patches, etc. The following output is a report of the items found that need to be addressed before running this software in a production environment. 389 Directory Server system tuning analysis version 14-JULY-2016. NOTICE : System is x86_64-unknown-linux3.10.0-957.27.2.el7.x86_64 (2 processors). [19/08/19:08:49:31] - [Setup] Info Would you like to continue? [19/08/19:08:49:39] - [Setup] Info yes [19/08/19:08:49:39] - [Setup] Info Choose a setup type: 1. Express Allows you to quickly set up the servers using the most common options and pre-defined defaults. Useful for quick evaluation of the products. 2. Typical Allows you to specify common defaults and options. 3. Custom Allows you to specify more advanced options. This is recommended for experienced server administrators only. To accept the default shown in brackets, press the Enter key. [19/08/19:08:49:39] - [Setup] Info Choose a setup type [19/08/19:08:49:40] - [Setup] Info 2 [19/08/19:08:49:40] - [Setup] Info Enter the fully qualified domain name of the computer on which you're setting up server software. Using the form <hostname>.<domainname> Example: eros.example.com. To accept the default shown in brackets, press the Enter key. Warning: This step may take a few minutes if your DNS servers can not be reached or if DNS is not configured correctly. If you would rather not wait, hit Ctrl-C and run this program again with the following command line option to specify the hostname: General.FullMachineName=your.hostname.domain.name [19/08/19:08:49:40] - [Setup] Info Computer name [19/08/19:08:49:42] - [Setup] Info xxxxx.xxxx.com [19/08/19:08:49:42] - [Setup] Info The servers must run as a specific user in a specific group. It is strongly recommended that this user should have no privileges on the computer (i.e. a non-root user). The setup procedure will give this user/group some permissions in specific paths/files to perform server-specific operations. If you have not yet created a user and group for the servers, create this user and group using your native operating system utilities. [19/08/19:08:49:42] - [Setup] Info System User [19/08/19:08:49:48] - [Setup] Info dirsrv [19/08/19:08:49:48] - [Setup] Info System Group [19/08/19:08:49:49] - [Setup] Info dirsrv [19/08/19:08:49:49] - [Setup] Info Server information is stored in the configuration directory server. This information is used by the console and administration server to configure and manage your servers. If you have already set up a configuration directory server, you should register any servers you set up or create with the configuration server. To do so, the following information about the configuration server is required: the fully qualified host name of the form <hostname>.<domainname>(e.g. hostname.example.com) the port number (default 389), the suffix, the DN and password of a user having permission to write the configuration information, usually the configuration directory administrator, and if you are using security (TLS/SSL). If you are using TLS/SSL, specify the TLS/SSL (LDAPS) port number (default 636) instead of the regular LDAP port number, and provide the CA certificate (in PEM/ASCII format). If you do not yet have a configuration directory server, enter 'No' to be prompted to set up one. [19/08/19:08:49:49] - [Setup] Info Do you want to register this software with an existing configuration directory server? [19/08/19:08:49:52] - [Setup] Info no [19/08/19:08:49:52] - [Setup] Info Please enter the administrator ID for the configuration directory server. This is the ID typically used to log in to the console. You will also be prompted for the password. [19/08/19:08:49:52] - [Setup] Info Configuration directory server administrator ID [19/08/19:08:49:57] - [Setup] Info admin [19/08/19:08:49:57] - [Setup] Info Password [19/08/19:08:50:06] - [Setup] Info Password (confirm) [19/08/19:08:50:08] - [Setup] Info The information stored in the configuration directory server can be separated into different Administration Domains. If you are managing multiple software releases at the same time, or managing information about multiple domains, you may use the Administration Domain to keep them separate. If you are not using administrative domains, press Enter to select the default. Otherwise, enter some descriptive, unique name for the administration domain, such as the name of the organization responsible for managing the domain. [19/08/19:08:50:08] - [Setup] Info Administration Domain [19/08/19:08:50:10] - [Setup] Info xxxx.com [19/08/19:08:50:10] - [Setup] Info The standard directory server network port number is 389. However, if you are not logged as the superuser, or port 389 is in use, the default value will be a random unused port number greater than 1024. If you want to use port 389, make sure that you are logged in as the superuser, that port 389 is not in use. [19/08/19:08:50:10] - [Setup] Info Directory server network port [19/08/19:08:50:12] - [Setup] Info 389 [19/08/19:08:50:12] - [Setup] Info Each instance of a directory server requires a unique identifier. This identifier is used to name the various instance specific files and directories in the file system, as well as for other uses as a server instance identifier. [19/08/19:08:50:12] - [Setup] Info Directory server identifier [19/08/19:08:50:13] - [Setup] Info xxxxxxx [19/08/19:08:50:13] - [Setup] Info The suffix is the root of your directory tree. The suffix must be a valid DN. It is recommended that you use the dc=domaincomponent suffix convention. For example, if your domain is example.com, you should use dc=example,dc=com for your suffix. Setup will create this initial suffix for you, but you may have more than one suffix. Use the directory server utilities to create additional suffixes. [19/08/19:08:50:13] - [Setup] Info Suffix [19/08/19:08:50:14] - [Setup] Info dc=xxxx, dc=com [19/08/19:08:50:14] - [Setup] Info Certain directory server operations require an administrative user. This user is referred to as the Directory Manager and typically has a bind Distinguished Name (DN) of cn=Directory Manager. You will also be prompted for the password for this user. The password must be at least 8 characters long, and contain no spaces. Press Control-B or type the word "back", then Enter to back up and start over. [19/08/19:08:50:14] - [Setup] Info Directory Manager DN [19/08/19:08:50:16] - [Setup] Info cn=Directory Manager [19/08/19:08:50:16] - [Setup] Info Password [19/08/19:08:50:19] - [Setup] Info Password (confirm) [19/08/19:08:50:21] - [Setup] Info The Administration Server is separate from any of your web or application servers since it listens to a different port and access to it is restricted. Pick a port number between 1024 and 65535 to run your Administration Server on. You should NOT use a port number which you plan to run a web or application server on, rather, select a number which you will remember and which will not be used for anything else. [19/08/19:08:50:21] - [Setup] Info Administration port [19/08/19:08:50:22] - [Setup] Info 9830 [19/08/19:08:50:22] - [Setup] Info The interactive phase is complete. The script will now set up your servers. Enter No or go Back if you want to change something. [19/08/19:08:50:22] - [Setup] Info Are you ready to set up your servers? [19/08/19:08:50:24] - [Setup] Info yes [19/08/19:08:50:24] - [Setup] Info Creating directory server . . . [19/08/19:08:50:30] - [Setup] Info Your new DS instance 'xxxxx' was successfully created. [19/08/19:08:50:30] - [Setup] Info Creating the configuration directory server . . . [19/08/19:08:50:33] - [Setup] Fatal Error: failed to open an LDAP connection to host 'xxxxxx.xxxx.com' port '389' as user 'cn=Directory Manager'. Error: unknown. [19/08/19:08:50:33] - [Setup] Fatal Failed to create the configuration directory server [19/08/19:08:50:33] - [Setup] Fatal Exiting . . . Log file is '/tmp/setupV6AAJP.log'

2 8

Location or package that has things like dsidm, dsconf
by Chris Motta 20 Aug '19

20 Aug '19

Hi- Newbie to 389 DS, but I like it so far, and it's working well for us. The docs reference tools like dsidm, dsconf, dsctl, but I cant' seem to find them. I'm wondering if I missed installing a package or missed a pathname. Any guidance? Thanks- jcm -- JC Motta (jcm) IT Consultant Apex Semi cmotta(a)apexsemi.com 408-805-0245 -- Confidential and Proprietary Communication of Apex Semiconductor Inc. If you are not the intended recipient, any dissemination, distribution or copying this communication is prohibited. If you think that you have received this email message in error, please email the sender.

3 4

First success, feedback & questions
by Nicolas Kovacs 20 Aug '19

20 Aug '19

Hi, I spent some more time reading and experimenting. I'm slowly beginning to see a path emerge in the directory jungle. Here's some odd notes, impressions and questions. 1. Setting up a basic directory using 389 DS is extremely easy. It's more or less just a matter of installing 389-ds-* related packages on the server, run the 389-*.pl setup script, connect to the database and then add user information. Doing the same thing using OpenLDAP is a relatively painful experience, since it involves manually configuring and setting up things using ldapmodify, ldapadd and a bunch of handcrafted LDIF files. My basic instinct tells me to rather opt for 389 DS for that reason. 2. I setup a complete 389 DS on a spare sandbox machine running CentOS 7 in my office. Since the 389 Console requires a graphical environment, I setup X11 and installed a basic window manager (WindowMaker, my first one back in 2001 under Slackware 7.1). Worked like a charm even on my very first attempt. I vaguely sense I like 389 DS. 3. I did a Quick & Dirty setup on a sandbox client desktop running OpenSUSE Leap 15.1 KDE. On the 389 DS server I created a few users and filled in the relevant POSIX account information. On the clients I opened YaST and pointed it to my 389 DS server instead of local authentication. No NFS for the moment, I just created the corresponding home directories manually for the moment. Logged out and found all my users in the SDDM login manager. Tried to log in. JustWorks(tm). :o) 4. Ideally, I would like to only install the minimal 389-ds-base package on the server, and then use a lightweight tool to manage my directory instead of the 389 Console that requires a graphical environment. As far as I can tell, there's solutions like PHPLdapAdmin or LDAP Account Manager for the server. Aren't there any simple GUI tools that I can install on my laptop (MacBook Pro running OpenSUSE Leap 15.1 instead of Mac OS) and that enable me to connect to my directory? I found some tools like GQ or JXplorer, but they all seem unmaintained/dead. Any suggestions? Cheers from the sunny South of France, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

2 1

Introduction & few notes
by Nicolas Kovacs 20 Aug '19

20 Aug '19

Hi, I'm new to this list, so let me introduce myself. I'm a 52-year old Austrian living in South France, and I'm the manager of a small IT company with a focus on Linux and Open Source Software. I'm the system administrator of our local school, where I have setup a small 100 % GNU/Linux network consisting of two servers running CentOS 7 and 20 desktop clients running OpenSUSE Leap 15.1. Currently the network uses a bone-headed single-sign-on configuration based on NIS and NFS. I'm well aware of the potential flaws of this setup, and I intend to replace it. In the past I've tried to wrap my head around LDAP, but I bluntly admit I failed miserably every time. I just read the "Single Sign On" chapter in the fine "Unix & Linux System Administration Handbook", which states 389 Directory Server as a preferable alternative to the plain OpenLDAP server. I have three sandbox machines in my office and some time to experiment, and I've even managed so far to install 389 DS on one of these machines using the online documentation and various tutorials. First things first. I'm a new user, so I checked out the project pat at https://www.port389.org/. I clicked on "Get started with a new install"... and got stuck since the documentation doesn't work on my system (CentOS 7). * https://www.port389.org/docs/389ds/howto/quickstart.html Eventually I figured out that Red Hat DS has a working documentation, although I felt a bit like someone looking for a receipt for pasta bolognese and getting a full-blown online course in food biochemistry. The QuickStart page sports a link "If you want to learn more about what ldap is, you should read our “ldap concepts” guide." So I clicked on that but unfortunately the link is dead. I admit I have yet to find a comprehensive introduction to LDAP that is suitable for folks like me with an IQ below 200. Any suggestions ? Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

4 5

Looking for installation documentation for CentOS 7
by Dan White 15 Aug '19

15 Aug '19

https://www.port389.org/docs/389ds/howto/howto-install-389.html appears to be geared toward 389-*-1.4.x while https://www.port389.org/docs/389ds/legacy/install-guide.html does not seem to reference anything past RHEL 4 I was told that v1.4.x is targeted for RHEL 8 and CentOS 8 is not yet released. See https://wiki.centos.org/About/Building_8 The latest package versions in the CentOS/EPEL 7 repos is 389-ds-base-1.3.8.4 and 389-ds-1.2.2 And I am extremely confuzzled about 389-console vs 389-ds-console vs cockpit-ui Are there any clues available ? ------------------------------------------------ “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes)

4 6

389 Directory Install Question
by Townsley, Eric L 08 Aug '19

08 Aug '19

Hi, Do you have to install as root? Thanks Eric Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.

3 3

Announcing 389 DIrectory Server 1.4.0.27
by Mark Reynolds 06 Aug '19

06 Aug '19

89 Directory Server 1.4.0.27 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.27 Fedora packages are available on Fedora 29 Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=36835167 <https://koji.fedoraproject.org/koji/taskinfo?taskID=36835167> Bodhi F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-76dbbf617c <https://bodhi.fedoraproject.org/updates/FEDORA-2019-76dbbf617c> The new packages and versions are: * 389-ds-base-1.4.0.27-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.27.tar.bz2> Highlights in 1.4.0.27 Bug fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *dnf install 389-ds-base*, then run *dscreate*. To install the Cockpit UI plugin use *dnf install cockpit-389-ds* See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation, setup, and upgrade See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. New UI Progress (Cockpit plugin) The new UI is fully functional! There are still parts that need to be converted to ReactJS, but everything works. Configuration Tab Finished Written in ReachJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes No Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.0.27 * Issue 50208 - make instances mark off based on dse.ldif not sysconfig * Issue 50530 - Directory Server not RFC 4511 compliant with requested attr "1.1" * Issue 50529 - LDAP server returning PWP controls in different sequence * Issue 50508 - UI - fix local password policy form -- 389 Directory Server Development Team

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2019