memberOf task problem
by John A. Sullivan III
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
13 years, 11 months
Proper upgrading procedure and the use of setup-ds-admin.pl -u
by Anthony Joseph Messina
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
14 years, 3 months
Kerberos SASL GSSAPI ssh error
by Prashanth Sundaram
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
14 years, 3 months
can't modify userPassword with proxy user: after code debugging...
by Roberto Polli
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."
14 years, 3 months
Chain on Update: Proxy Auth Fails
by Mrugesh Karnik
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.
14 years, 3 months
Trouble building 389-admin-1.1.8
by Matt Adams
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
14 years, 3 months
URGENT: some problems with 389 1.2.1
by Rich Megginson
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.
14 years, 3 months
Data corruption after upgrade.
by Theunis De Klerk
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
14 years, 3 months
Broken bash environment with ldap users.
by Dumbo Q
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!
14 years, 3 months