389-users August 2009

389-users@lists.fedoraproject.org

24 participants
33 discussions

memberOf task problem
by John A. Sullivan III 18 Dec '09

18 Dec '09

Hello, all. We are in the process of upgrading from 8.0 to 8.1. We've hit a few glitches along the way but most has gone well. However, we wanted to implement the new memberOf functionality. We successfully added the plugin by editing dse.ldif and enabled it from the console. However, we've been unsuccessful in having existing group membership assigned to the memberOf attribute. We first tried to run fixup-memberOf.pl but the script does not exist. There is a template.fixup-memberOf.pl but this does not seem to have been built into a final script. We then thought we would use the new task feature of the console. We went to cn=memberof task,cn=tasks,cn=config and tried to create the task object. There was no nsDirectoryServerTask objectclass. We added an nstask but then found there was no basedn attribute we could add. We then created an extensibleobject instead but still not basedn attribute. Finally, we resorted to ldapmodify (we hesitated just because we are not very familiar with the command line tools). First, we did: dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: fixMemberOf basedn: o=Internal,dc=ssiservices,dc=biz The Internal Organization has several organizations under it (for various clients) and then user organizational units under those organizations. Although it generated no errors, it did not seem to work. Perhaps I just don't know how to test it. However, the following did not return an memberOf data: /usr/lib64/mozldap/ldapsearch -b "ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory Manager" -w - -h ldap uid=myid memberOf Doing /usr/lib64/mozldap/ldapsearch -b "ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D "cn=Directory Manager" -w - -h ldap uid=myid showed me plenty of attributes but nothing for memberOf I also tried creating the task with a basedn of ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz in case it did not change objects lower in the tree. Still no success. Finally I tried: dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config changetype: add objectclass: top objectclass: nsDirectoryServerTask cn: fixMemberOf basedn: o=Internal,dc=ssiservices,dc=biz adding new entry cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config ldap_add: Object class violation ldap_add: additional info: unknown object class "nsDirectoryServerTask" And received the expected unknown object class error. What are we doing wrong? Are these documentation bugs? Are there application bugs or do we simply not know what we are doing with tasks and memberOf? How do we get the memberOf information into our existing user objects? Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan(a)opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society

5 13

Proper upgrading procedure and the use of setup-ds-admin.pl -u
by Anthony Joseph Messina 28 Aug '09

28 Aug '09

I am currently running the following: 389-admin-1.1.8-3.fc11.x86_64 389-admin-console-1.1.4-1.fc11.noarch 389-admin-console-doc-1.1.4-1.fc11.noarch 389-adminutil-1.1.8-3.fc11.x86_64 389-console-1.1.3-3.fc11.noarch 389-ds-1.1.3-4.fc11.noarch 389-ds-base-1.2.1-1.fc11.x86_64 389-ds-base-debuginfo-1.2.1-1.fc11.x86_64 389-ds-console-1.2.0-4.fc11.noarch 389-ds-console-doc-1.2.0-4.fc11.noarch 389-dsgw-1.1.4-1.fc11.x86_64 Those are the packages that were the initial group that supported the renaming of Fedora DS to 389 DS. I plan to upgrade with "yum upgrade" today as some bugs have been fixed. What is the proper upgrading procedure for 389 DS? Can I simply do a "yum update" and expect everything to work or do I always need to merge rpmnew files and run setup-ds-admin.pl after each "yum update"? I ask for two reasons: 1) I was hit by https://bugzilla.redhat.com/show_bug.cgi?id=518418 and have since recreated my servers with the above packages 2) I noticed that while using SSL, the setup-ds-admin.pl requires me to delete the CA cert that was previously installed and re-import it (crazy). I'd like to make sure don't have these servers crap out again. Thanks a lot. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

2 5

Kerberos SASL GSSAPI ssh error
by Prashanth Sundaram 27 Aug '09

27 Aug '09

Hello, I am having some trouble with the FDS PAM PTA. I am trying to authenticate against AD I was trying to verify the password authentication to AD. The only time it does is kinit <ad user>. To test this, I was trying to setup ssh on a client box and configure it to bind to the FDS directory. Then I tried ssh user@localhost on client box, it will not accept any password and return below error. debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Next authentication method: publickey Here are my questions. 1. Do I have to make any changes in ldap.conf file like below entries? # RFC 2307 (AD) mappings # pam_login_attribute uid (enable) # pam_lookup_policy (enable) # pam_password crypt (enable) # pam_password ad (update ad passwd from unix) 2. Edit the following files for kerberos. I was trying to follow this link for documentation. http://aput.net/~jheiss/krbldap/howto.html * krb5.conf * kadm5.acl * kdc.conf 3. Edit /etc/pam.d/system-auth and ldapserver. 4. Do I need to have CA cert installed on Admin and Directory servers for ssh? I mean, I do not have any certificates installed to 389-ds currently. Is there any other steps missing here? Thanks, Prashanth

1 0

389 Directory Server 1.2.2 has been released
by Rich Megginson 26 Aug '09

26 Aug '09

The 389 Directory Server team is pleased to announce the release of version 1.2.2. There are two updated packages: 389-ds-base-1.2.2-1 and 389-admin-1.1.8-4 This release fixes several critical bugs that were in 1.2.1. We apologize for any inconvenience caused by those bugs. * Full bug list - https://bugzilla.redhat.com/showdependencytree.cgi?id=389_1.2.2&hide_resolv… * https://bugzilla.redhat.com/show_bug.cgi?id=487425 slapd crashes after changelog is moved * https://bugzilla.redhat.com/show_bug.cgi?id=504651 Need to store additional attributes in Retro Changelog * https://bugzilla.redhat.com/show_bug.cgi?id=509472 db2index (all) does not reindex all the db backends correctly * https://bugzilla.redhat.com/show_bug.cgi?id=518418 Package rename shuts down server, results in unconfigured package * https://bugzilla.redhat.com/show_bug.cgi?id=518520 pre hashed salted passwords do not work * https://bugzilla.redhat.com/show_bug.cgi?id=518544 large entries cause server SASL responses to fail * https://bugzilla.redhat.com/show_bug.cgi?id=519065 Fails to start if attrcrypt can't unwrap keys The Fedora 10, 11, and 12 (rawhide) packages should be showing up in the mirrors shortly. The FC6 packages are available for download. * Release Notes - http://directory.fedoraproject.org/wiki/Release_Notes * Download - http://directory.fedoraproject.org/wiki/Download

1 0

can't modify userPassword with proxy user: after code debugging...
by Roberto Polli 26 Aug '09

26 Aug '09

Following http://www.mail-archive.com/fedora-directory- users(a)redhat.com/msg09799.html As of now, no solution but give to proxy user write access on entries.. if you succeeded in another way you're welcome to post. I looked+gdb the code of modify.c: when I try to change userPassword another flow is done. modify.c: ... if (has_password_mod): PasswordFlow return StandardFlow return in PasswordFlow, the function op_shared_allow_pw_change() change the password ignoring controls and evaluating proxy user access permissions as a local user in StandardFlow, all the controls are evaluated and the proxy_dn is set To make a specific request using only the interesting controls, avoiding evaluation of unneeded ones (), I used the following options to ldapmodify| passwd * -g -R -J 2.16.840.1.113730.3.4.18 Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali."

2 3

Chain on Update: Proxy Auth Fails
by Mrugesh Karnik 24 Aug '09

24 Aug '09

Hi all, I've been trying to set up Chain on Update on CentOS DS 8.1. The master-slave replication works. Search queries return data from the replicated database on the slave perfectly. When I send an update request, the slave binds with the master with the proper credentials but the ACI evaluation fails on the master. From the ACI logs on the master, it seems to me that the master evaluates the ACIs for the multiplexor bind dn rather than for the original user identity. This leads me to believe that somehow, proxy authentication is not happening. How do I solve this problem? In my setup, Following is the suffix and db configuration on the slave: # Suffix dn: cn="ou=Roster,dc=example,dc=com",cn=mapping tree,cn=config cn: "ou=Roster,dc=example,dc=com" objectClass: top objectClass: extensibleObject objectClass: nsMappingTree nsslapd-state: backend nsslapd-backend: RosterData nsslapd-backend: RosterDataChain nsslapd-distribution-plugin: /usr/lib/dirsrv/plugins/libreplication-plugin.so nsslapd-distribution-funct: repl_chain_on_update nsslapd-parent-suffix: "dc=example,dc=com" # Database dn: cn=RosterData,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance nsslapd-suffix: ou=Roster,dc=example,dc=com # Replica dn: cn=replica,cn="ou=Roster,dc=example,dc=com",cn=mapping tree,cn=config cn: replica objectClass: top objectClass: nsds5replica objectClass: extensibleObject nsds5replicaroot: ou=Roster,dc=example,dc=com nsds5replicaid: 21 nsds5replicatype: 2 nsds5flags: 0 nsds5ReplicaBindDN: cn=dirhost1.example.net,ou=Replication Managers,cn=config nsds5ReplicaBindDN: cn=dirhost2.example.net,ou=Replication Managers,cn=config # Chaining Database dn: cn=RosterDataChain,cn=chaining database,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: RosterDataChain nsslapd-suffix: ou=Roster,dc=example,dc=com nsFarmServerUrl: ldap://dirhost1.example.net ldap://dirhost2.example.net nsCheckLocalACI: on nsUseStartTls: on nsBindMethod: nsMultiplexorBindDn: cn=dirslave1.example.net,ou=Replication Managers,cn=config nsMultiplexorCredentials: secret I've tried with the following ACI combinations on ou=Roster,dc=example,dc=com on dirhost1 and dirhost2 1> aci: (targetattr="*") (version 3.0; acl "Proxy access for chain-on-update"; allow (proxy) userdn="ldap:///cn=dirslave1.example.net,ou=replication managers,cn=config";) 2> aci: (target=ldap:///uid=*,ou=Users,ou=Roster,dc=example,dc=com)(targetattr=*) (version 3.0; acl "Proxy access for chain-on-update as normal users"; allow (proxy) userdn="ldap:///cn=dirslave1.example.net,ou=Replication Managers,cn=config";) I see the following error in the ACI logs: [20/Aug/2009:12:57:24 +051800] NSACLPlugin - conn=201 op=2 (main): Deny write on entry(uid=mrugesh.karnik,ou=users,ou=roster,dc=example,dc=com).attr(userPassword) to cn=dirslave1.example.net,ou=replication managers,cn=config: no aci matched the subject by aci(70): aciname= "Write access to personal info", acidn="ou=users,ou=roster,dc=example,dc=com" Thanks, Mrugesh P.S. The users can modify their own userpassword attribute properly.

1 1

Trouble building 389-admin-1.1.8
by Matt Adams 21 Aug '09

21 Aug '09

Folks, I'm having some trouble building 389-admin-1.1.8 from the source archive. The error I'm getting is configure: checking for LDAPSDK... checking for --with-ldapsdk... no checking for --with-ldapsdk-inc... using ../mozldap-6.0.6/mozilla/dist/public/ldap checking for --with-ldapsdk-lib... using /usr/local/lib checking for pkg-config... (cached) /usr/bin/pkg-config checking for mozldap with pkg-config... configure: error: LDAPSDK not found, specify with --with-ldapsdk-inc|-lib. Which is very odd since I had no problems using the same options to build 389-ds-base. Nothing else has changed. The configure line I'm using is ./configure \ --prefix=/usr/local/dirsrv \ --with-ldapsdk-lib=/usr/local/lib \ --with-ldapsdk-bin=/usr/local/bin \ --with-ldapsdk-inc=../mozldap-6.0.6/mozilla/dist/public/ldap Does anyone have any ideas as to why configure refuses to find LDAPSDK? I've tried several different combinations and nothing seems to work. Thanks in advance, Matt -- Matt Adams Development & Network Services, Cypress Interactive http://cypressinteractive.com, http://edsuite.com

1 0

URGENT: some problems with 389 1.2.1
by Rich Megginson 20 Aug '09

20 Aug '09

Do not upgrade to 389 1.2.1 until you have read this message. Bug 518418 - Package rename shuts down server, results in unconfigured package This was caused by renaming the packages from fedora-ds to 389. This causes RPM to first remove the fedora-ds-base and fedora-ds-admin packages which triggers this %preun scriptlet in the spec: %preun if [ $1 = 0 ]; then /sbin/service %{pkgname} stop >/dev/null 2>&1 || : /sbin/chkconfig --del %{pkgname} fi So not only does it shutdown your directory and admin servers, it removes the chkconfig settings, including your run level settings. This was an unforeseen consequence of the package rename, and we compounded the problem by pushing the package out to stable instead of testing (where it would have likely been caught). If you intend to upgrade despite this problem, please first save your run level configuration by using chkconfig --list dirsrv, and schedule the upgrade when you can tolerate a service interruption. Is there any other way around this problem? Bug 518520 - pre hashed salted passwords do not work If you use an external mechanism to generate salted SSHA passwords, authentication will fail, because the server does not take into account the salt length. We have a patch for this ready to go for 1.2.2.

1 0

Data corruption after upgrade.
by Theunis De Klerk 20 Aug '09

20 Aug '09

Hi All, I am having an issue with 389DS after an upgrade and I was hoping someone could help me out. According to people on the 389 IRC Channel, someone has had this before. Firstly, please understand I am a little out of my league, so please be patient. So this afternoon, our RHEL5 box did a yum update which included 389DS. But after the upgrade, user's can't login using profiles in ldap. All the data is there, but it seems that the password fields are messed. As an example, our apache websites use Directory Server for Authentication. If I take any of the usernames and passwords that exist and try login, I get a "password mismatch" in apache. I.e. wrong password. This worked before the upgrade. But .. If I, using Apache Directory Studio, edit the password on one of those profiles, and commit. That person can login. Its as if the password attributes data is corrupted, and has to be manually reset to work again. Users can't even reset their own passwords, as the Perl module (Net::LDAP) can modify the password value, but it still won't let them login. I can even use Directory studio to verify the password, and its correct. Seems the only way I can use a password is if I use Directory Studio to change it. Has anyone has this? Or know where I can start looking, or how to fix it? Not sure what other information I need to give. Thanks, Theunis

2 10

Broken bash environment with ldap users.
by Dumbo Q 18 Aug '09

18 Aug '09

I setup central authentication using centos ds. On a test box I got it working just the way i wanted, but then when I went to deploy the config files to some other servers, things went screwy. Hopefully someone else has seen this happen when deploying ldap..?? Heres what I did. 1. Copied my config files from the working server to a new one. Here is a listing of the files that have been copied: /etc/authconfig /etc/auto.home /etc/auto.master /etc/ldap.conf /etc/libuser.conf /etc/login.defs /etc/nsswitch.conf /etc/openldap/ldap.conf /etc/pam.d/system-auth /etc/pam.d/system-auth-ac /etc/security/access.conf 2. Once the files are in place, I tried to ssh as username "dumbo" uid=1000 in ldap. I can login successfully, but the bash environment is all screwed up. Here is what i mean by that. example 1. echo hello |grep hello returns no output. No pipes seem to work. grep alone on a file works. example 2. See the attached zip file. I saved the output of bash --login -vx from both a local user and an ldap user. It appears that when the ldap user logs in, it is unable to parse backticks. Note the output is just 50 lines, which shows what happens when the user runs /etc/bashrc on login. Some other steps i've taken. 1. wiped out the home directory for the ldap user (although it still worked fine on my first test box). 2. diffed and confirmed that all of the files i copied as well as /etc/profile.d are identical on both servers. 3. I set the first line in /etc/bashrc to "set > /tmp/test1", and compared output of the environment variables from a local and ldap user. The output is is the same other the of course the UID's and PID numbers. I am at a complete loss as to what the problem is. any help would be appreciated. Thanks!

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2009