Using "overlay dynlist" with Ubuntu Karmic 9.10 LDAP server using slapd.d (not slapd.conf) ?
by Shamika Joshi
Hi
The desired implementation is to control user logins on different lab
machines based on the project groups.
Scenario: Bob is part of project group 'mars' & John is part of 'venus' then
I have added lab machines x1-x3 to group 'mars' & y1-y3 to group venus. Now
I want John to only access machines allocated for project 'mars' i.e x1 to
x3 & John to access machines allocated for 'venus' i.e y1 to y3
I went through this
link<http://www.hurricanelabs.com/september2009_login_security_using_openldap_...>learned
that it can be achieved using "overlay dynlist". Please correct me
if I've got it wrong.
However my lab server is Ubuntu 9.10 (karmic koala) and it is using slapd.d
(not slapd.conf)
So now if I want to attempt to use "overlay dynlist" how should I go about
it? Has anyone done this before? Any help will be appreciated.
Thanks
Shamika
11 years
group in groups
by alois blasbichler
Hello list
We use our Openldap with a lot of applications like apache, squid, samba ...
What for us whould be very usefull is to define in ldap groups with
users and other groups therin.
Is this possible in Ldap or maybe with the nss-module ?
I cant find any documentation.
Thank you
luis
11 years
password-hash
by Paul Soucy
Hi,
I am running OpenLDAP 2.4 on Ubuntu 9.10. I am trying to get user
passwords to be stored {SHA}. I understand the way to do this is by
adding password-hash {SHA} line to the slapd.conf file. However, on
Ubuntu 9.10 the /etc/slapd.conf is a directory not a file. What am I
missing here?
11 years
openldap bug: libldap mutex hang on ldap_int_sasl_mutex
by Jeremiah Martell
After digging into this more, this definitely looks like a bug in openldap.
I modified openldap to make all mutex's recursive.
Then my GSSAPI rebind proc worked properly, and the search searched
all referrals and found the result (two referrals later).
Thanks,
- Jeremiah
---------- Forwarded message ----------
From: Jeremiah Martell <inlovewithgod(a)gmail.com>
Date: Mon, Mar 29, 2010 at 3:11 PM
Subject: libldap mutex hang on ldap_int_sasl_mutex
To: openldap-technical(a)openldap.org
I'm using openldap-2.4.18, library libldap_r.
I have three windows active directory servers setup:
childA.parent.example.com
parent.example.com
childB.parent.example.com
I do a LDAP+GSSAPI bind to childA.parent.example.com.
The bind succeeds.
I do a search that returns referrals, (I know I need to be referred to
parent, and then childB in order to find my result),
and I have openldap follow referrals for me.
My rebind proc is a function that only calls:
ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL,
LDAP_SASL_AUTOMATIC, sasl_driver, params );
where sasl_driver and params is the same parameters that I used for
the initial bind call to childA.
After the seach call, the debug it looks like this:
> ldap_chase_v3referrals, where ref[0] = parent.example.com
> myGSSAPIrebindProc
> ldap_sasl_interactive_bind_s
< ldap_sasl_interactive_bind_s
< myGSSAPIrebindProc
< ldap_chase_v3referrals
> ldap_chase_v3referrals, where ref[0] = childB.parent.example.com
> myGSSAPIrebindProc
> ldap_sasl_interactive_bind_s
> ldap_chase_v3referrals, where ref[0] = childA.parent.example.com
< ldap_chase_v3referrals
> ldap_chase_v3referrals, where ref[0] =
ForestDnsZones.parent.example.com
> myGSSAPIrebindProc
> ldap_sasl_interactive_bind_s ... HANG ON MUTEX
Since this is hanging on a mutex, that would suggest a code bug.
Perhaps the ldap_int_sasl_mutex needs to be a recursive mutex?
Or should my rebind proc do something different than call
ldap_sasl_interactive_bind_s?
Any other ideas appreciated too.
Thanks,
- Jeremiah
--
- Jeremiah Martell
http://inlovewithGod.com
11 years
Partial replication
by Joe Friedeggs
Is it possible to replicate, on a slave, two branches of the DIT (only)? I have several instances of LDAP running on servers throughout the world. Connection to some of these from our support location is not dependable. I want to do something similar to this:
Main LDAP (here, master):
dc=example,dc=com
|
+--o=support
|
+--o=location_A
|
+--o=location_B
|
+--o=location_C
In Location A (remote slave):
dc=example,dc=com
|
+--o=support
|
+--o=location_A
In Location B (remote slave):
dc=example,dc=com
|
+--o=support
|
+--o=location_B
Location A & B are two different customers, therefore it would not be prudent to replicate Location B's users in Locations A. But I need the Support group to exist in all locations.
Can this be done using syncrepl?
Another thought is to have LDAP Masters existing in each location, and somehow replicate the Support branch to each (mirrormode?). Should this be the approach?
Thanks,
Joe
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:O...
11 years
RE: Partial replication
by Joe Friedeggs
The e-mail thread seems to have wandered a bit, hoping I am replying to the correct one.
I've tested both methods, ACL vs 'syncrepl search filter', both seem to work well for me. I agree with Andrew's point that controlling this via the ACLs on the provider is more secure (in my case).
Thanks for all the help and insight.
Joe
----------------------------------------
> On Thu, Apr 01, 2010 at 09:53:07PM +0200, Zdenek Styblik wrote:
>
>>>> you want to replicate. So, let's say you use cn=mirrorA,dc=domain,dc=tld
>>>> for replication, then allow this cn=mirrorA to read only
>>>> o=support,dc=example,dc=com and o=location_A,dc=example,dc=com, but nowhere
>>>> else.
>>>
>>> I have used that technique for a fairly complex design with a central
>>> office and many small satellites. It works OK *provided* you never change
>>> the list of entries that can be seen by the replicas. The syncrepl
>>> system has no way to evaluate the effect of an ACL change (and probably
>>> no way to know that one has happenned).
>>>
>>
>> Could you please elaborate more on this one?
>
> My design requirements were similar to Joe's: I had a large central
> server holding the master data for a lot of customers. Each customer
> needed a local replica of their own data plus some subset of the
> service-provider data. In my case the subset was not even complete
> subtrees: the customers were allowed to see certain attributes of
> certain entries only. I had to protect against the possibility that
> someone might modify the config on a customer server to obtain data
> that they should not have.
>
> As there was already a comprehensive default-deny access-control
> policy in place, I just factored in the replica servers as principals
> with the right to see all data that should be replicated to that site
> and nothing else. That meant that every replica server could have an
> identical syncrepl clause which just copies everything it can see from
> the entire DIT.
>
> The downside is that if any access permissions change then the
> replicas may not reflect the correct new subset of data.
>
>> Because I'd say if you refuse
>> access later to some DN then it must be like DN has been deleted. Same goes
>> for adding. I mean, syncrepl won't see data. And it checks, well it should
>> check, for changes in some regular intervals, right?
>
> The problem is that syncrepl does not check every entry exhaustively.
> That would be very inefficient (though I would like a way to force it
> periodically). The master server maintains something like a timestamp
> on the whole DIT, and when the replica server connects they just have
> to compare timestamps and transfer things that have changed in the
> interval between the two. (This is a gross simplification of the
> actual protocol, but close enough for the discussion).
>
> Now imagine that I change an ACL which affects the visibility of some
> entries. The entries themselves have not changed, so the timestamps do
> not change and the replication process will not know that the replica
> data should change.
>
> Worse still, I might change the membership of a group that is
> referenced in an ACL. The replication process would transfer the group
> but would not know that some other entries have changed visibility.
>
>> I have no need for nor experience with this, yet it's somewhat interesting.
>
> It is a powerful technique, but the designer *and operators* of such a
> system must be aware of the pitfalls.
>
>> ACLs of anykind in OpenLDAP are kinda ... PITA, no offense to anybody!!! :)
>> It just needs a lot of work to maintain and stuff (please please, no
>> bashing).
>
> ACLs of any kind in any system (LDAP, file system, RDBMS etc) can be
> hard to get right and harder to modify correctly at a later date. It
> all depends on the policy that you are trying to implement. You should
> think of ACLs as programs and expect to need programmer-level skill to
> work on them. You may find this paper helpful:
>
> http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
>
> Of all the LDAP servers that I have worked with, I find OpenLDAP's
> ACLs are the easiest for implementing non-trivial policies.
>
> Andrew
> --
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:O...
11 years
memberOf overlay
by Chris Alavoine
Hi all,
Am trying to get the memberOf overlay attribute working with openLDAP.
I need to authenticate to a Cisco ASA 5510 and set up group mapping policy.
I've been round the houses quite a few times and got pretty close but no
Marlboro Light (let alone a cigar).
My slapd.conf looks like this:
# /etc/ldap/slapd.conf
#
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/misc.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/ldap
moduleload back_bdb
#syncprov added by PT 2009-01-19
moduleload syncprov
# cja/ess/2010.03.29 - added memberOf overlay
moduleload memberof.la
overlay memberof
sizelimit 500
tool-threads 1
backend bdb
database bdb
suffix "dc=essence"
rootdn "cn=admin,dc=essence"
rootpw xxxxxxxxxxxxxxxxxxxxxxx
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass,entryCSN,entryUUID eq
lastmod on
checkpoint 512 30
replogfile /var/lib/ldap/replog
#syncprov added by PT 2009-01-19
overlay syncprov
syncprov-checkpoint 10 5
syncprov-sessionlog 100
access to attrs=userPassword,sambaNTPassword,sambaLMPassword
by dn="cn=admin,dc=essence" write
by dn="cn=samba,dc=essence" write
by dn="cn=guest,dc=essence" read
by anonymous auth
by self write
by * none
access to dn.base="" by * read
access to *
by dn="cn=admin,dc=essence" write
by dn="cn=samba,dc=essence" write
by * read
# end
I've added an LDIF as follows:
dn: cn=vpnusers,ou=Groups,dc=essence
objectclass: groupOfNames
cn: vpnusers
member: userid=chris.alavoine,ou=Users,dc=essence
Which seems to enter ok.
I'm using phpldapadmin to look at my directory. The new group "vpnusers"
shows up ok and if I do a:
ldapsearch -x -b "dc=essence" '(uid=chris.alavoine)' memberOf
I get:
# chris.alavoine, Users, essence
dn: uid=chris.alavoine,ou=Users,dc=essence
memberOf: cn=vpnusers,ou=Groups,dc=essence
Unfortunately, when I try and query this information from the Cisco it's not
picking up on the memberOf attribute. I've set up attribute mapping on the
Cisco which allows me to convert the memberOf attribute into something
readable by the Cisco but it's not getting that far.
I'm using Ubuntu 8.04 and openLDAP 2.4.9
Any help much appreciated.
c:)
--
ACS (Alavoine Computer Services)
Chris Alavoine
mob +44 (0)7724 710 730
www.alavoinecs.co.uk
11 years
forgotten rootdn psw
by Francis, Steve (IHG)
ok...So i'm an ID10T!! LOL. But seriously, I setup an OpenLdap server
and migrated /etc/passwd to it, and all is well: however, I did that
months ago, and you guessed it, somehow I'm having a "senior" moment,
and can't remember the psw for the rootdn, so that I can add another
user to the Ldap server. I'm sure there is probably a way to decode the
"hashed/encrypted" password. Any help would be greatly appreciated. I
really don't want to have to delete everything and start again, but if
that's what I must do, then so be it.
Thanks in advance,
Steve Francis
Technical Advisor - zSeries, zLinux, z/OS
IHG
Alpharetta Data Center
Ph: 770-442-7157
Cell: 770-906-3122
IM: francisihg
11 years
Sample Large ldiff file to support 1K users
by Meena Ram
Dear folks:
If anyone has sample large ldiff file which supports around 1000 users please let me know. Require it for some particular purpose so that it saves some time.Really appreciate your help on this. Send me the link or the ldif file itself
Cheers!!!!!!!!!!!
RAM
11 years
too many open files and over 1K xinetd running
by Seger, Mark
I'm using xinetd forwarding to allow a number of compute nodes that don't have a direct path to our ldap server to get forward on by a host that does. When running a highly parallel job that starts over 1K instances at the same time, I see all these xinetd instances also start up on my forwarding server and in fact they don't seem to go away, at not any time soon. Meanwhile back on my ldap server I see number of 'too many open files' errors in /var/log/messages and if I try to "su user" on one of the nodes I'll see it hang for awhile. I have bumped the number of open files very high on the ldap server and in fact:
[root@aicgateway ~]# cat /proc/sys/fs/file-nr
5610 0 201116
So out of a pool of 200K we're only using 5K.
Anyhow, I'm wondering if there are any special tricks to configuring the environment to handling this type of load on ldap OR should it be able to handle it the way I'm currently configured? Any special tuning hints? Any more info I can supply?
-mark
11 years
