Re: Problems creating a Samba4 LDAP Backend
by Howard Chu
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/
13 years, 8 months
Re: ldap_add: Server is unwilling to perform (53) error:
by shanmuga priya
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/
13 years, 8 months
a problem with centralized authentication using openLDAP
by Tamer Al-Khouli
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 ?!
13 years, 8 months
Solaris 10 Client ; Openldap 2.4 Server; supportedControl supportedsaslmechanisms
by Mark S
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!
13 years, 8 months
RE: Solaris 10 Native LDAP Client TLS
by farhan ahmed
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&ref...
13 years, 8 months
Problems creating a Samba4 LDAP Backend
by Andrew Bartlett
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.
13 years, 8 months
Re: ldap_add: Server is unwilling to perform (53) error:
by vinodh kumar
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
13 years, 8 months
ldap_add: Server is unwilling to perform (53) error:
by vinodh kumar
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
13 years, 8 months
Loading the refint module globally?
by Andrew Bartlett
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.
13 years, 8 months
proxycache examples
by Andy Cobaugh
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
13 years, 8 months
