openldap-technical March 2008

openldap-technical@openldap.org

55 participants
54 discussions

Re: Problems creating a Samba4 LDAP Backend
by Howard Chu 21 Mar '08

21 Mar '08

simo wrote: > On Wed, 2008-03-19 at 17:33 -0700, Howard Chu wrote: >> Searching on memberOf doesn't make a lot of sense to me, when you could simply >> read the group object directly. When is this actually a useful thing to do? An >> alternative would be to make the memberOf overlay intercept these filters and >> rewrite them in terms of member. > > Premise: here I am thinking beyond what AD is doing as I use the > memberOf concept in another project. > >> From my usage memberOf makes it very simple to find all the groups a > member is part of even if that membership derives from nested grouping. Ah, an interesting point, but probably a separate discussion. Note that the OpenLDAP memberOf overlay doesn't handle nested groups. > It's very clear that most of the time you have an identity and you want > to know what this Identity is part of, not the other way. No, not clear at all. A very common application of "groups" is for things like email lists. In that case, an MTA knows a specific group (the name of the email list), and needs to know all of the members. Other times (e.g. access control) you know an identity (current user) and want to know if the identity belongs to a particular group (for an authorization check). In that case, it is an equal amount of work to look in the user's entry for a memberOf value as to look in the group entry for the particular member value. In practice, because groups may be referenced frequently for multiple users, the group entries will be hot in the server cache and so the member lookup is actually cheaper. The frequency with which the question "what groups do I belong to" is asked is extremely low in most applications. The frequency with which the question "is XX a member of this group" is asked is very high in most applications. E.g., the libc initgroups() call needs to know what groups you belong to; that call typically occurs only once at the beginning of a login session. After that the result is essentially cached by the kernel. The result is cached in the kernel because the subsequent "is XX a member of group YY" questions happen so frequently as a process accesses system resources. > So you really want to do a single search on one entry, rather than a > huge search on the whole directory to find out (including local > calculation for nesting) what groups include that identity as member, by > parsing all groups one by one. > It is as simple as that. No, not simple at all. Yes, ideally you would like to be able to look in a single place and get the answer to "what privileges does user X have" but that doesn't actually mean what you're implying. In particular, the "single place" you're looking isn't necessarily that user's own entry. In most cases, that's the worst place to use because users generally have full write privileges to their own data, and the data comprising their set of privileges really belongs to the sysadmin, not to the individual user. Ideally, you write to the privilege set and read from the privilege set in the same way, in the same place. As an administrator, this simple consistency makes life easier. The memberOf concept is fundamentally broken if you actually rely on it for privilege determination because it is one step removed from how privileges are actually assigned by the sysadmin. (I.e., the sysadmin doesn't assign membership privileges to a user by writing to the memberOf attribute, therefore memberOf is not authoritative.) > Now for what concern the Samba4 problem, I think we should be more > creative and first understand in which cases we might hit a problem with > plugins like memberOf. I am sure some of these cases are just normal > possible inconsistencies that can happen even in a normal AD server if > you do many modifications at the same time. For these cases we just have > to try not to make them more probable or problematic than what they are > now. > In other cases we might think of doing aggressive caching/prediction in > our internal transactions. It might require some more work, but it could > be a viable option, and also drive some more performance as dealing with > an external LDAP is necessarily slower. > Finally, if caching/prediction is not possible, we can think of writing > overlays/slapi plugins directly for the LDAP server of choice be it > OpenLDAP or Fedora Directory Server or anything else. This third option > would require some more work and will be server specific, and perhaps > involve some creative thinking wrt licensing, but it is certainly a > viable option we should not discard. After all, these LDAP servers have > a plugin system with defined APIs exactly to solve those problems that > cannot be solved merely by external interaction. Agreed. And frankly, there's already an existence proof that this approach is viable. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ldap_add: Server is unwilling to perform (53) error:
by shanmuga priya 21 Mar '08

21 Mar '08

On Tue, Mar 18, 2008 at 12:13 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, March 18, 2008 12:12 AM +0530 vinodh kumar > <vinstce(a)gmail.com> wrote: > > > > so , we need to add a entry objectclass : account in our .ldif file > > right??? > > and do i need to add the above in schema file ???? > > > > sorry if my doubt is silly!! bare with me :) > > If you have loaded the cosine schema, then all you need to do is add the > objectClass: account into your ldif file. > hello sir.. i am also one in that project..well we already loaded cosine schema..and it contains account ..as you said we added object class account in our ldif file..but still we are getting the very same error??where are we missing??? > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Future is now.. @http://shanmugapriya.wordpress.com/

2 1

a problem with centralized authentication using openLDAP
by Tamer Al-Khouli 20 Mar '08

20 Mar '08

Hi everyone, I am trying to set up and openLDAP server for centralized authentication. I used self-signed certificate and put the generated server.pem file in the slapd.conf, then i checked it using the following command: $openssl s_client -connect localhost:636 -showcerts and i got : Verify return code: 18 (self signed certificate) which, as i read, indicates that things fine with the server. Next, i tired: $ldapsearch -x "uid=user1" and i got : ============ # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=user1 # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ============= Even though there's an entry with that uid, so i ran slapd in the debug mode 9 using this command: $/usr/sbin/slapd -d9 -h "ldap:/// ldaps:///" 1>/var/log/ldaplog 2>&1 and i did the ldapsearch again and got this from the log: ========================== TLS trace:SSL_accept:error in SSLv3 read client certificate A .... commection_read(14): unable to get TLS client DN, error=49 id=6 .... connection_read(14): input error=-2 id=6, closing. ========================== I thought the error seen in the log could be related to the fact that i didn't do anything on the client side to give it a certificate, so i assigned the same server.pem file to the client in the /etc/openldap/ldap.conf file as follows: .... TLS_CACERT /etc/openldap/server.pem TLS_REQCERT allow .... and issued the ldapsearch command again, and i got this: ldap_bind: Can't contact LDAP server (-1) additional info: TLS: hostname does not match CN in peer certificate. I am stuck here and don't know what to do, can any one help, please ?!

2 1

Solaris 10 Client ; Openldap 2.4 Server; supportedControl supportedsaslmechanisms
by Mark S 20 Mar '08

20 Mar '08

I am running a Solaris 10 x86 environment and have built Openldap 2.4.8 as by LDAP server platform. On the client side I have run the following ldapclient command to configure my clients; ldapclient manual -v -a credentialLevel=anonymous \ -a authenticationMethod=none \ -a defaultsearchbase='dc=nyc,dc=example,dc=com' \ -a defaultServerList=10.0.0.1 \ -a serviceSearchDescriptor=passwd:ou=people,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=group:ou=group,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=services:ou=services,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=protocols:ou=protocols,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=rpc:ou=rpc,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=hosts:ou=hosts,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=networks:ou=networks,dc=nyc,dc=example,dc=com?one \ -a serviceSearchDescriptor=netgroup:ou=netgroup,dc=nyc,dc=example,dc=com?one I have ended up with the following /var/ldap/ldap_client_file NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 10.0.0.1 NS_LDAP_SEARCH_BASEDN= dc=nyc,dc=example,dc=com NS_LDAP_AUTH= none NS_LDAP_CACHETTL= 0 NS_LDAP_CREDENTIAL_LEVEL= anonymous NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= services:ou=services,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= protocols:ou=protocols,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= rpc:ou=rpc,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= hosts:ou=hosts,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= networks:ou=networks,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= netgroup:ou=netgroup,dc=nyc,dc=example,dc=com?one NS_LDAP_SERVICE_SEARCH_DESC= automount:ou=automount,dc=nyc,dc=example,dc=com?one In general all is working fine. My one concerns is that when I have been monitoring the ldap logs i see the below query over and over again Mar 18 12:10:23 ldap1.nyc.example.com slapd[6642]: [ID 848112 local4.debug] conn=9423 fd=38 ACCEPT from IP=10.0.1.182:42757 (IP=0.0.0.0:389) Mar 18 12:10:23 ldap1.nyc.example.com slapd[6642]: [ID 469902 local4.debug] conn=9423 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Mar 18 12:10:23 ldap1.nyc.example.com slapd[6642]: [ID 744844 local4.debug] conn=9423 op=0 SRCH attr=supportedControl supportedsaslmechanisms Mar 18 12:10:23 ldap1.nyc.example.com slapd[6642]: [ID 167594 local4.debug] conn=9423 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 18 12:10:23 ldap1.nyc.example.com slapd[6642]: [ID 218904 local4.debug] conn=9423 op=1 UNBIND Mar 18 12:10:23 ldap1.nyc.example.com slapd[6642]: [ID 952275 local4.debug] conn=9423 fd=38 closed Does anyone know why the Solaris ldap_cachemgr process keeps performing this query over and over again and what I might do to stop it. Thanks!

2 4

RE: Solaris 10 Native LDAP Client TLS
by farhan ahmed 20 Mar '08

20 Mar '08

Hi Guys, I have done it for Solaris 10 but now I am facing problem in Solaris 9. Please help me Still no luck with LDAP native client on Solaris 9. I am getting following messageMar 16 02:02:59 web04 sendmail[3700]: [ID 293258 mail.warning] libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't contact LDAP serverBut when I run /usr/lib/ldap/ldap_cachemgr -g, I get following which shows there is no problemcachemgr configuration:server debug level 0server log file "/var/ldap/cachemgr.log"number of calls to ldapcachemgr 19cachemgr cache data statistics:Configuration refresh information: Previous refresh time: 2008/03/17 23:55:23Next refresh time: 2008/03/18 00:55:23Server information: Previous refresh time: 2008/03/17 23:55:23Next refresh time: 2008/03/18 00:05:23server: 203.221.221.83, status: UPCache data information: Maximum cache entries: 256Number of cache entries: 0 ldapclient -vvv manual -a defaultServerList=10.10.10.10 -a defaultSearchBase=dc=test,dc=com -a authenticationMethod=tls:simple -a credentialLevel=proxy -a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=com -a proxyPassword=test Note: Same command works for Solaris 10I really want to use LDAP native client rather than openldap client which is hassle to install gcc padle pam_ldap etc on 50 servers.Please help me guys.Thanks,Farhan From: farhhanahmed(a)hotmail.comTo: openldap-technical(a)openldap.orgSubject: Solaris 10 Native LDAP Client TLSDate: Fri, 14 Mar 2008 11:55:59 +0000 Hello Guys, I am having some issues to configure LDAP Native client with TLS. Please help me to sort out this issueLDAP Server: Linux (OpenLdap), LDAP Client: Solaris 10 (Native Client)When I run following command to test, it works fine, ldapsearch -v -h test -p 636 -Z -P /var/ldap/cert8.db -b "dc=test,dc=com" -s base "objectclass=*"ldapsearch: started Fri Mar 14 18:11:57 2008ldap_init( test, 636 )filter pattern: objectclass=*returning: ALLfilter is: (objectclass=*)version: 1dn: dc=test,dc=comobjectClass: dcObjectobjectClass: organizationo: test.com web sitedc: test1 matchesBut When I run ldapclient command to initialize ldapclient, it doesn't work, please guide me where I am doing wrongldapclient -v manual -a defaultServerList=10.10.10.10-a defaultSearchBase=dc=test,dc=com -a authenticationMethod=tls:simple -a serviceAuthenticationMethod=pam_ldap:tls:simple -a serviceAuthenticationMethod=keyserv:tls:simple -a serviceAuthenticationMethod=passwd-cmd:tls:simple-a credentialLevel=proxy -a proxyDN=cn=Manager,ou=People,dc=test,dc=com -a proxyPassword=passwdAfter that when I run ldaplist command, I get following in /var/adm/messagesMar 14 18:15:16 subx05-t1 nfs4cbd[1638]: [ID 293258 daemon.warning] libsldap: Status: 91 Mesg: openConnection: failed to initializeTLS security (security library: bad database.)Please help me guys :) I know I am very near to get it workingThanks,Farhan at CarPoint.com.au It's simple! Sell your car for just $30 _________________________________________________________________ New music from the Rogue Traders - listen now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=832&refer…

3 2

Problems creating a Samba4 LDAP Backend
by Andrew Bartlett 19 Mar '08

19 Mar '08

Over the past few weeks, I have been testing OpenLDAP as a backend for Samba4. I've been working with the OpenLDAP team on my requirements, and there has been some really good outcomes - the memberOf module has been improved, as has the refint module. However, I seem to have hit a brick wall, in the form of (internal) transaction support. I need an LDAP backend to support internal transactions - that is, when for example a 'member' modification is made, all the memberOf attributes must be updated before the call returns. Similarly, if a user or group moves, all the member/memberOf attributes that link the user to their groups must also move, before the modrdn returns. The Samba4 test ldap.js tests this behaviour extensively, because I want to be sure it works. As understand the discussion I've had with the OpenLDAP team, OpenLDAP does not support this, and will not support it for perhaps some time. Similarly, from discussions with the Fedora DS team at the CIFS developer days, I understand that it is similarly very unlikely that Fedora DS will support internal transactions. (It also does not support subtree renames, which we also need). The fact that LDAP does not expose a transaction API was always going to be a difficult part of having Samba4 use an LDAP backend, but I always assumed that if we pushed the really hard bit - updating linked attributes - into the LDAP server that we could at least always have a consistent DB. (It turns out this is one of the primary uses of transactions anyway.) But without that consistency, and without knowing as a caller if all the updates succeed, I'm worried about how we can safely move forward. This is especially disappointing because I was hoping that these free, replicating LDAP servers might solve the backed replication problem for me, without needing to use AD replication. Does anybody have any ideas or suggestions on how I could get around this? Should we drop the LDAP backend as a nice idea, but not going to work, and focus on DRS or some other form of replication? Can someone imagine a sane way to reconstruct the DN links, including subtree renames, without the help of the LDAP backend? Could we ban subtree renames (as Fedora DS does), and try to handle this ourselves (with pre/post checks and a good deal of prayer)? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.

2 5

Re: ldap_add: Server is unwilling to perform (53) error:
by vinodh kumar 17 Mar '08

17 Mar '08

On Mon, Mar 17, 2008 at 11:29 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, March 17, 2008 11:26 PM +0530 vinodh kumar <vinstce(a)gmail.com > > > wrote: > > our ldif file is, > > > > > > > > dn: cn:new,dc=example,dc=com > > > > objectClass:posixAccount > > cn:new > > uid:new > > displayname:neww > > homedirectory > > > homedirectory:/home/new > > I suggest you research into objectClasses and valid objectClass chains. > The error you've gotten is quite correct, you've failed to provide a > structural objectClass in your entry. Think of it in terms of object > oriented programming -- Every entry object must be of a specific class, > which can then be added onto with auxiliary information. posixAccount is > auxiliary, you need to add a valid structural OC to your entry. > > "account" may be the one you're looking for: oh thanks:) actually i have a doubt that where to add this??? objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' > SUP top STRUCTURAL > MUST userid > MAY ( description $ seeAlso $ localityName $ > organizationName $ organizationalUnitName $ host ) > ) > > > --Quanah > > so , we need to add a entry objectclass : account in our .ldif file right??? and do i need to add the above in schema file ???? sorry if my doubt is silly!! bare with me :) -- regards vinodh i blog @ http://vinsvision.wordpress.com

2 1

ldap_add: Server is unwilling to perform (53) error:
by vinodh kumar 17 Mar '08

17 Mar '08

hello all, we are trying to setup a ldap server which uses the mysql as back-end instead of bdb backend.we have installed slapd and ldap-utils in debian-etch .we also have installed mylibodbc, mysql-client-5,mysql-server-5. we have established the mysql-ODBC connectivity and tested the connectivity using isql.we have configured the slapd.conf file to connect mysql and when we tried to add entries using ldapadd , we get the following err ldap_add: Server is unwilling to perform (53) additional info: operation not permitted within namingContext this is the slapd.conf file # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ############################# Global Directives: # Features to permit #allow bind_v2 # 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 # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_sql # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 ############################## > > ######################################### > # Specific Backend Directives for bdb: > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > backend sql > checkpoint 512 30 > > ####################################################################### > # Specific Backend Directives for 'other': > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > #backend <other> > > ####################################################################### > # Specific Directives for database #1, of type bdb: > # Database specific directives apply to this databasse until another > # 'database' directive occurs > database sql > suffix "dc=example,dc=org" > rootdn "cn=admin,dc=example,dc=org" > rootpw ldap > dbname ldap > dbuser new > dbpasswd new > #insentry_query "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) > values ((select max(id)+1 from ldap_entries),?,?,?,?)" > #upper_func "upper" > #strcast_func "text" > #concat_pattern "?||?" > #has_ldapinfo_dn_ru no > #schemacheck on > > lastmod off > > > # The base of your directory in database #1 > suffix "dc=example,dc=org" > > # rootdn directive for specifying a superuser on the database. This is > needed > # for syncrepl. > rootdn "cn=admin,dc=example,dc=org" > rootpw secret > # Where the database file are physically stored for database #1 > directory "/var/lib/ldap" > > # For the Debian package we use 2MB as default but be sure to update this > # value if you have plenty of RAM > dbconfig set_cachesize 0 2097152 0 > > # Sven Hartge reported that he had to set this value incredibly high > # to get slapd running at all. See http://bugs.debian.org/303057 > # for more information. > > # Number of objects that can be locked at the same time. > dbconfig set_lk_max_objects 1500 > # Number of locks (both requested and granted) > dbconfig set_lk_max_locks 1500 > # Number of lockers > dbconfig set_lk_max_lockers 1500 > > # Indexing options for database #1 > index objectClass eq > cn,sn,ou > # Save the time that the entry gets modified, for database #1 > lastmod on > > # Where to store the replica logs for database #1 > # replogfile /var/lib/ldap/replog > > # The userPassword by default can be changed > # by the entry owning it if they are authenticated. > # Others should not be able to see it, except the > # admin entry below > # These access lines apply to database #1 only > access to attrs=userPassword,shadowLastChange > by dn="cn=admin,dc=example,dc=org" write > by anonymous auth > by self write > by * none > > # Ensure read access to the base for things like > # supportedSASLMechanisms. Without this you may > # have problems with SASL not knowing what > # mechanisms are available and the like. > # Note that this is covered by the 'access to *' > # ACL below too but if you change that as people > # are wont to do you'll still need this if you > # want SASL (and possible other things) to work > # happily. > access to dn.base="" by * read > > # The admin dn has full write access, everyone else > # can read everything. > access to * > by dn="cn=admin,dc=example,dc=org" write > by * none > > # For Netscape Roaming support, each user gets a roaming > # profile for which they have write access to > #access to dn=".*,ou=Roaming,o=morsnet" > # by dn="cn=admin,dc=example,dc=org" write > # by dnattr=owner write > > ####################################################################### > # Specific Directives for database #2, of type 'other' (can be bdb too): > # Database specific directives apply to this databasse until another > # 'database' directive occurs > #database <other> > > # The base of your directory for database #2 > #suffix "dc=debian,dc=org" > -- regards vinodh i blog @ http://vinsvision.wordpress.com

3 8

Loading the refint module globally?
by Andrew Bartlett 17 Mar '08

17 Mar '08

I've been wondering why I couldn't get the wonders of refint and memberOf to play together, and even went to the extent of writing a testsuite to prove that they could work (indeed, they do). However, I eventually found my problem - while memberOf works very nicely as a global overlay, the refint module does not (yet :-). With it loaded per-backend (for now), it seems to work. Any chance someone could knock me up a patch for that, much like was done so well for memberOf? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.

3 10

proxycache examples
by Andy Cobaugh 15 Mar '08

15 Mar '08

I'm working in an environment where the server I wish to use for user and group lookups (through nss_ldap on RHEL) limits the number of queries per IP per day to 200. I want to cache as much as I can locally, for as long as I can. This data hardly ever changes, so the longer I can cache, the better. I'm thinking of caching everything for at least a day, if not longer. Does the pcache overlay currently support such long ttl's? Does anyone have any working pcache configs that can be used to cache the kind of searches performed by nss_ldap ? -- Andy Cobaugh

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2008