389-users October 2013

389-users@lists.fedoraproject.org

22 participants
22 discussions

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

multi-valued nsAccountLock
by Pierre ROUDIER 10 Jul '15

10 Jul '15

Hi all, RedHat DS's doc states that the nsAccountLock attribute is multi-valued [1]. Some tests with 389ds led me to think it's also true for 389ds. I cannot think of any reason explaining why it would have to be multi-valued. Do you have any idea? Thank you. [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server…

3 2

changelog
by Denise Cosso 16 Apr '15

16 Apr '15

Hi, How to modify the attribute nsslapd-encryptionalgorithm in Centos? Thanks, Denise Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES. dn: cn=changelog5,cn=config [...] nsslapd-encryptionalgorithm: AES --- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu: De: Rich Megginson <rmeggins(a)redhat.com> Assunto: Re: [389-users] changelog Para: "Denise Cosso" <guanaes51(a)yahoo.com.br> Data: Terça-feira, 4 de Junho de 2013, 16:34 On 06/04/2013 01:26 PM, Denise Cosso wrote: Hi, Rich CentOS release 6.3 (Final) 389-ds-base-libs-1.2.10.2-20.el6_3.x86_64 389-ds-1.2.2-1.el6.noarch 389-dsgw-1.1.10-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-1.2.10.2-20.el6_3.x86_64 As far as replication goes - you will need to use a security layer (SSL, TLS, or GSSAPI) to protect the clear text password on the wire As far as encrypting it in the changelog - not sure Denise --- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu: De: Rich Megginson <rmeggins(a)redhat.com> Assunto: Re: [389-users] changelog Para: "General discussion list for the 389 Directory server project." <389-users(a)lists.fedoraproject.org> Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br> Data: Terça-feira, 4 de Junho de 2013, 16:11 On 06/04/2013 12:39 PM, Denise Cosso wrote: Hi, Description of problem: When a userPassword is changed in a server with changelog, the hashed password is logged and also a cleartext pseudo-attribute version. It looks like this: change:: replace: userPassword userPassword: {SHA256}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q== - replace: unhashed#user#password unhashed#user#password: secret12 This unhashed version is used in winsync where the cleartext version of the password must be written to the AD. Now if the DS is involved in replication with another DS, the change will be replayed exactly as it is logged to the other DS replicas, including the cleartext pseudo-attribute password. What platform? What version of 389-ds-base are you using? thanks, Denise -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

2 2

389 Master - Master Replication
by Santos Ramirez 03 Oct '14

03 Oct '14

Good Morning, We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated. Santos U. Ramirez Linux Systems Administrator National DCP, LLC 150 Depot Street Bellingham, Ma. 02019 Phone: 508-422-3089 Fax: 508-422-3866 Santos.Ramirez(a)natdcp.com<mailto:Santos.Ramirez@natdcp.com> This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.

3 9

389 directory server crash
by Mitja Mihelič 21 Nov '13

21 Nov '13

Hi! We are having problems with some our 389-DS instances. They crash after receiving an update from the provider. The crash happened twice after about a week of running without problems. The crashes happened on two consumer servers but not at the same time. The servers are running CentOS 6x with the following 389DS packages installed: 389-ds-console-doc-1.2.6-1.el6.noarch 389-console-1.1.7-1.el6.noarch 389-adminutil-1.1.15-1.el6.x86_64 389-dsgw-1.1.10-1.el6.x86_64 389-ds-base-debuginfo-1.2.11.15-14.el6_4.x86_64 389-admin-1.1.29-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.11.15-14.el6_4.x86_64 389-ds-base-libs-1.2.11.15-14.el6_4.x86_64 389-admin-console-1.1.8-1.el6.noarch We are in the process of replacing the Centos 5x base consumer+provider setup with a CentOS 6x base one. For the time being, the CentOS 6 machines are acting as consumers for the old server. They run for a while and then the replicated instances crash though not at the same time. One of the servers did not want to start after the crash, so I have run db2index on its database. It's been running for four days and it has still not finished. All I get from db2index now are these outputs: [09/Jul/2013:13:29:11 +0200] - reindex db: Processed 65095 entries (pass 1104) -- average rate 53686277.5/sec, recent rate 0.0/sec, hit ratio 0% The other instance did start up, but the replication process did not work anymore. I disabled the replication to this host and set it up again. I chose "Initialize consumer now" and the consumer crashed every time. I have enabled full error logging and could find nothing. I have read a few threads (not all, I admit) on this list and http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes and tried to troubleshoot. The crash produced the attached core dump and I could use your help with understanding it. As well as any help with the crash. If more info is needed I will gladly provide it. Regards, Mitja

2 17

SSL simple (I hope) question
by Russell Beall 24 Oct '13

24 Oct '13

I am working out the best way to enable SSL in a new 389 directory suite setup. I found that when updating the SSL certificate, there are problems with the symmetric keys used for attribute encryption. The instructions simply say to delete those entries and have the directory create new keys on startup after a certificate update. This worries me because if there is encrypted data locked to the lost keys, wouldn't that remain unrecoverable? Is there a best practice regarding installation of SSL certificates? Should I follow the self-signed cert steps and set a long lifetime on that cert, and then separate that from the SSL connectivity certificate (which we buy from an official certificate authority)? Thanks, Russ.

2 3

(no subject)
by harry.devine＠faa.gov 23 Oct '13

23 Oct '13

We have been working this problem for two weeks debugging. We have 389-ds running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap clients authenticate correctly to the RHEL6 389-ds directory server and with 'id' command can see all groups a user belongs too. The same command in a RHEL6 ldap client using sssd shows ONLY the primary group. If we change the ldap clients to point at the RHEL5 389-ds directory server the same results occur. The one consistency is any RHEL6 ldap client we setup will authenticate to either RHEL5 or RHEL6 but the entire list of groups that user belongs to do not transfer independent of server version. We have enumerate set to true and we have ldap_group_member set to uniqueMember. These seems to point to the ldap client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're not sure how to correct or is it a bug. HELP? Thanks! Harry Devine Common ARTS Software Development AJM-245 (609)485-4218 Harry.Devine(a)faa.gov

4 5

Issues with group names on RHEL6
by harry.devine＠faa.gov 22 Oct '13

22 Oct '13

(In my haste to post this, my first email didn't have a subject. My apologies!) We have been working this problem for two weeks debugging. We have 389-ds running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap clients authenticate correctly to the RHEL6 389-ds directory server and with 'id' command can see all groups a user belongs too. The same command in a RHEL6 ldap client using sssd shows ONLY the primary group. If we change the ldap clients to point at the RHEL5 389-ds directory server the same results occur. The one consistency is any RHEL6 ldap client we setup will authenticate to either RHEL5 or RHEL6 but the entire list of groups that user belongs to do not transfer independent of server version. We have enumerate set to true and we have ldap_group_member set to uniqueMember. These seems to point to the ldap client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're not sure how to correct or is it a bug. HELP? Thanks! Harry Devine Common ARTS Software Development AJM-245 (609)485-4218 Harry.Devine(a)faa.gov

2 1

MemberOf Plugin - experiences?
by Vesa Alho 22 Oct '13

22 Oct '13

Hi, I have a commercial application which could use MemberOf information from LDAP (ref http://directory.fedoraproject.org/wiki/MemberOf_Plugin). Does many people use this plugin and what are your experiences with it? Currently we are only using "uniquemember" attribute in Group entries. Some stuff on the Issues list look worrying to me: "Membership attribute is currently hard-coded to be "member"" "We really should make this work with MMR. " MemberOf is not crucial to us. So, before I start experimenting, it would be great to know if it's "worth" my time. -Mr. Vesa Alho

5 11

slapi_ldap_init segmentation fault
by Russell Beall 18 Oct '13

18 Oct '13

Hi, I am trying to port a plugin from our Sun DS to 389. I worked through a number of API differences and got it to compile. When I tried to run a test I keep getting segmentation faults in the pthread library regardless of how I compile or link the code. I boiled it down to the following single line-item code which produces the crash: int main (int argc, char **argv) { LDAP *ld = slapi_ldap_init( ldaphost, 389, 0, 1); } The stack trace is this: #0 0x0000003c61009220 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x0000003dd3c240b9 in PR_Lock () from /lib64/libnspr4.so #2 0x0000003dd70ae6b8 in set_snmp_interaction_row () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x0000003dd7066771 in slapi_ldap_init_ext () from /usr/lib64/dirsrv/libslapd.so.0 #4 0x000000000040065f in main (argc=<value optimized out>, argv=<value optimized out>) at basictest_crash.c:22 This is under RedHat 6 and this version of the directory: 389-Directory/1.2.11.23 B2013.275.1555 I had a much longer email here until I dug into the server code where the crash occurs. I found that when running the plugin code independently of the server, the snmp_collator code was not initialized and a thread mutex was still NULL when attempting to lock it. I hacked in this to force initialization: diff ~/Downloads/389-ds-base-1.2.11.23/ldap/servers/slapd/snmp_collator.c ~/Downloads/389-ds-base-1.2.11.23-modified/ldap/servers/slapd/snmp_collator.c 239a240 > if (! interaction_table_mutex) interaction_table_mutex = PR_NewLock(); Linking against the hacked libslapd.so causes my test to function. So… I've basically figured out what I needed to know by deep hacking, but I thought I should go ahead and post this in case it might be useful for discussion and possible patching. When developing this plugin for Sun DS I worked with a locally executable version for testing as well as with it installed in the server. It would definitely be useful to continue being able to develop independently of the server without always having to plug it in to test. Regards, Russ.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users October 2013