Re: Security between server and client nodes.
by Raffael Sahli
On 12/02/2011 07:49 AM, Jayavant Patil wrote:
>
>
> On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil
> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote:
>
> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
> >
> >
> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> > >>
> > >>
> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> > >> <jayavant.patil82(a)gmail.com
> <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>
>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>>> wrote:
> > >>
> > >>
> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>
> > <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com
> <mailto:public@raffaelsahli.com>>>> wrote:
> > >> >>Hi
> > >>
> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
> > >> >>Please read the manual
> http://www.openldap.org/doc/admin24/tls.html
> > >> >Ok.
> > >>
> > >> >>And tree security:
> > >> >>On my server, a client user can only see his own object:
> > >> >Are you using simple authentication mechanism?
> > >>
> > >> >>Maybe create a rule like this:
> > >> >>access to filter=(objectClass=
> > >> >>simpleSecurityObject)
> > >> >> by self read
> > >> >> by * none
> > >>
> > >> >I am not getting what the ACL rule specifies. Any suggestions?
> > >>
> > >>
> > >> I have two users ldap_6 and ldap_7. I want to restrict a
> user to
> > >> see his own data only.
> > >> In slapd.conf, I specified the rule as follows:
> > >> access to *
> > >> by self write
> > >> by * none
> > >>
> > >> But ldap_6 can see the ldap_7 user entries (or vice
> versa) with
> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> > >>
> > >> Any suggestions?
> > >>
> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>>
> wrote:
> > >Yes, that's exactly the rule I wrote above.
> >
> > >access to filter=(objectClass=
> > >simpleSecurityObject)
> > > by self read
> > > by * none
> >
> >
> > >Maybe you have to change the objectClass to posixAccount, or
> both or
> > >whatever....
> >
> > >access to
> > >filter=(|(objectClass=
> simpleSecurityObject)(objectClass=posixAccount))
> > > by self read
> > > by * none
> >
> >
> > >Just add this rule before the global rule "access to *"
> >
> >
> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
> >
> > >And if you search like this with bind "admin dn", you will see
> every
> > >object....
> > >You have to bind with user ldap_6 and not with root
> > But anyway client user knows the admin dn and rootbindpassword. So,
> > with this he will look into all directory information to which he is
> > not supposed to do.
> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
> >
> > So, how to avoid this?
> >
>
>
> >>Why client user knows the admin dn and pw????????
>
> >Because /etc/ldap.conf file on client contains admin dn and pw.
>
> >Each user information in the directory contains the following
> entries(here, e.g. ldap_6)
>
>
> >dn: uid=ldap_6,ou=People,dc=abc,dc=com
> >uid: ldap_6
> >cn: ldap_6
> >sn: ldap_6
> >mail: ldap_6(a)abc.com <mailto:ldap_6@abc.com>
> >objectClass: person
> >objectClass: organizationalPerson
> >objectClass: inetOrgPerson
> >objectClass: posixAccount
> >objectClass: top
> >objectClass: shadowAccount
> >objectClass: hostObject
> >objectClass: simpleSecurityObject
> >shadowLastChange: 13998
> >shadowMax: 99999
> >shadowWarning: 7
> >loginShell: /bin/bash
> >uidNumber: 514
> >gidNumber: 514
> >homeDirectory: /home/ldap_6
> >host: *
> >userPassword::
> e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>
>
> >So, what should be the ACL rule so that each user can see his
> data only? I tried but not getting the required, even the >user
> himself is unable to see his own data.
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
> The user itself is unable to see its own info.
>
> [ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com" "(cn=ldap_6)" -h
> server
> ldap_initialize( ldap://server )
> filter: (cn=ldap_6)
> requesting: All userApplication attributes
> # extended LDIF
> #
> # LDAPv3
> # base <dc=abc,dc=com> with scope subtree
> # filter: (cn=ldap_6)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 32 No such object
>
> # numResponses: 1
>
>
Please inspect the debug log on your slapd server. If you set the log
level to 128 or 256, you will see any error about "32 No such object".
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
12 years, 11 months
cannot rename back-sql tables
by Matthew Hallsworth
Hi list,
I have searched far and wide for a solution to this but cannot find
anywhere where it is possible to configure back-sql as such.
I am trying to interface openldap with a MySQL backend using the
standard back-sql configuration, with one exception - every 'ldap_*'
prefixed table needs to be named 'custom_ldap_*' as we are trying to fit
in LDAP support into an existing product which requires the additional
tables to make this work to conform with existing schema.
What I've found is, I can get the LDAP requests working perfectly via a
test database using standard 'ldap_*' notation, but I cannot for the
life of me get the system to handle different table names properly.
My config file, "/etc/openldap/slapd.conf", on CentOS 5.2 shows the
following:
<snip>
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Allow LDAPv2 client connections. This is NOT the default.
#allow bind_v2
loglevel -1
logfile /var/log/ldap.log
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib64/openldap
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# sql definitions for mysql access
#######################################################################
database sql
dbname ldaptest
readonly on
suffix "dc=rams,dc=com,dc=au"
dbuser ldaptest
dbpasswd abc123
subtree_cond "custom_ldap_entries.dn LIKE CONCAT('%',?)"
children_cond "custom_ldap_entries.dn LIKE CONCAT('%',?)"
id_query "SELECT id,keyval,oc_map_id,dn FROM custom_ldap_entries
WHERE dn=?"
oc_query "SELECT
id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM
custom_ldap_oc_mappings"
at_query "SELECT
name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u
FROM custom_ldap_attr_mappings WHERE oc_map_id=?"
has_ldapinfo_dn_ru no
lastmod off
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
#database bdb
#suffix "dc=my-domain,dc=com"
#rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
</snip>
Now, when I run "/usr/sbin/slapd -d -5" and attempt to do a general
query on the ldap server using "ldapsearch -x -b 'dc=rams,dc=com,dc=au'"
I get the following feedback from openldap:
<snip>
# extended LDIF
#
# LDAPv3
# base <dc=rams,dc=com,dc=au> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 80 Other (e.g., implementation specific) error
# numResponses: 1
</snip>
And, the debug output displays:
<snip>
...
==>backsql_search(): base="dc=rams,dc=com,dc=au",
filter="(objectClass=*)", scope=2, deref=0, attrsonly=0, attributes to
load: all
==>backsql_get_db_conn()
==>backsql_open_db_conn(3)
daemon: epoll: listen=8 active_threads=0 tvp=NULL
<==backsql_open_db_conn(3)
backsql_open_db_conn(3): connected, adding to tree.
<==backsql_get_db_conn()
==>backsql_dn2id("dc=rams,dc=com,dc=au") matched expected
backsql_dn2id("dc=rams,dc=com,dc=au"): id_query "SELECT
id,keyval,oc_map_id,dn FROM custom_ldap_entries WHERE dn=?"
backsql_dn2id("dc=rams,dc=com,dc=au"): id=1 keyval=1 oc_id=1
dn=dc=rams,dc=com,dc=au
>>> dnPrettyNormal: <dc=rams,dc=com,dc=au>
<<< dnPrettyNormal: <dc=rams,dc=com,dc=au>, <dc=rams,dc=com,dc=au>
<==backsql_dn2id("dc=rams,dc=com,dc=au"): err=0
==>backsql_id2entry()
backsql_id2entry(): retrieving all attributes
==>backsql_get_attr_vals(): oc="organizationalUnit" attr="objectClass"
keyval=1
backsql_get_attr_vals(): error executing attribute count query 'SELECT
COUNT(*) FROM ldap_entry_objclasses,ldap_entries,company WHERE
company.id=? AND ldap_entries.id=ldap_entry_objclasses.entry_id AND
ldap_entries.keyval=company.id and ldap_entries.oc_map_id=1'
Return code: -1
nativeErrCode=1146 SQLengineState=S0002 msg="[unixODBC][MySQL][ODBC
3.51 Driver][mysqld-5.0.45]Table 'ldaptest.ldap_entry_objclasses'
doesn't exist"
<==backsql_id2entry()
==>backsql_oc_get_candidates(): oc="inetOrgPerson"
==>backsql_srch_query()
==>backsql_process_filter()
<==backsql_process_filter() succeeded
<==backsql_srch_query() returns SELECT DISTINCT
ldap_entries.id,contact.id,'inetOrgPerson' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,contact WHERE
contact.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
Constructed query: SELECT DISTINCT
ldap_entries.id,contact.id,'inetOrgPerson' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,contact WHERE
contact.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
id: '2'
backsql_oc_get_candidates(): error executing query
Return code: -1
nativeErrCode=1146 SQLengineState=S0002 msg="[unixODBC][MySQL][ODBC
3.51 Driver][mysqld-5.0.45]Table 'ldaptest.ldap_entries' doesn't exist"
==>backsql_oc_get_candidates(): oc="organizationalUnit"
==>backsql_srch_query()
==>backsql_process_filter()
<==backsql_process_filter() succeeded
<==backsql_srch_query() returns SELECT DISTINCT
ldap_entries.id,company.id,'organizationalUnit' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,company WHERE
company.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
Constructed query: SELECT DISTINCT
ldap_entries.id,company.id,'organizationalUnit' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,company WHERE
company.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
id: '1'
backsql_oc_get_candidates(): error executing query
Return code: -1
nativeErrCode=1146 SQLengineState=S0002 msg="[unixODBC][MySQL][ODBC
3.51 Driver][mysqld-5.0.45]Table 'ldaptest.ldap_entries' doesn't exist"
send_ldap_result: conn=3 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=80
ber_flush: 14 bytes to sd 9
0000: 30 0c 02 01 02 65 07 0a 01 50 04 00 04 00 0....e...P....
ldap_write: want=14, written=14
0000: 30 0c 02 01 02 65 07 0a 01 50 04 00 04 00 0....e...P....
conn=3 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=
...
</snip>
In summary, I feel that there is some kind of missing configuration
variable either in documentation or tutorials online that really doesn't
allow you to fully specify alternate table names for the default 4 main
tables in the back-sql implementation. If this is due to the backend
being experimental then so be it - however I really need some kind of
quantified 'yes' or 'no' as to whether what I'm trying to achieve is
possible at all.
TIA
Matthew Hallsworth
15 years, 6 months
Re: Security between server and client nodes.
by Jayavant Patil
On Fri, Dec 2, 2011 at 12:19 PM, Jayavant Patil
<jayavant.patil82(a)gmail.com>wrote:
>
>
> On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil <jayavant.patil82(a)gmail.com
> > wrote:
>
>> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli <
>> public(a)raffaelsahli.com> wrote:
>> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
>> >
>> >
>> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
>> > >>
>> > >>
>> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
>> > >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
>> > <mailto:jayavant.patil82@gmail.com
>>
>> > <mailto:jayavant.patil82@gmail.com>>> wrote:
>> > >>
>> > >>
>> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
>> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
>> > <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>>
>> wrote:
>> > >> >>Hi
>> > >>
>> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
>> > >> >>Please read the manual
>> http://www.openldap.org/doc/admin24/tls.html
>> > >> >Ok.
>> > >>
>> > >> >>And tree security:
>> > >> >>On my server, a client user can only see his own object:
>> > >> >Are you using simple authentication mechanism?
>> > >>
>> > >> >>Maybe create a rule like this:
>> > >> >>access to filter=(objectClass=
>> > >> >>simpleSecurityObject)
>> > >> >> by self read
>> > >> >> by * none
>> > >>
>> > >> >I am not getting what the ACL rule specifies. Any suggestions?
>> > >>
>> > >>
>> > >> I have two users ldap_6 and ldap_7. I want to restrict a user to
>> > >> see his own data only.
>> > >> In slapd.conf, I specified the rule as follows:
>> > >> access to *
>> > >> by self write
>> > >> by * none
>> > >>
>> > >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
>> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
>> > >>
>> > >> Any suggestions?
>> > >>
>> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
>> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
>> > >Yes, that's exactly the rule I wrote above.
>> >
>> > >access to filter=(objectClass=
>> > >simpleSecurityObject)
>> > > by self read
>> > > by * none
>> >
>> >
>> > >Maybe you have to change the objectClass to posixAccount, or both or
>> > >whatever....
>> >
>> > >access to
>> > >filter=(|(objectClass=
>> simpleSecurityObject)(objectClass=posixAccount))
>> > > by self read
>> > > by * none
>> >
>> >
>> > >Just add this rule before the global rule "access to *"
>> >
>> >
>> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>> >
>> > >And if you search like this with bind "admin dn", you will see every
>> > >object....
>> > >You have to bind with user ldap_6 and not with root
>> > But anyway client user knows the admin dn and rootbindpassword. So,
>> > with this he will look into all directory information to which he is
>> > not supposed to do.
>> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
>> >
>> > So, how to avoid this?
>> >
>>
>>
>> >>>Why client user knows the admin dn and pw????????
>>
>> >>Because /etc/ldap.conf file on client contains admin dn and pw.
>>
>> >>Each user information in the directory contains the following
>> entries(here, e.g. ldap_6)
>>
>>
>> >>dn: uid=ldap_6,ou=People,dc=abc,dc=com
>> >>uid: ldap_6
>> >>cn: ldap_6
>> >>sn: ldap_6
>> >>mail: ldap_6(a)abc.com
>> >>objectClass: person
>> >>objectClass: organizationalPerson
>> >>objectClass: inetOrgPerson
>> >>objectClass: posixAccount
>> >>objectClass: top
>> >>objectClass: shadowAccount
>> >>objectClass: hostObject
>> >>objectClass: simpleSecurityObject
>> >>shadowLastChange: 13998
>> >>shadowMax: 99999
>> >>shadowWarning: 7
>> >>loginShell: /bin/bash
>> >>uidNumber: 514
>> >>gidNumber: 514
>> >>homeDirectory: /home/ldap_6
>> >>host: *
>> >>userPassword:: e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>>
>>
>> >>So, what should be the ACL rule so that each user can see his data
>> only? I tried but not getting the required, even >>the user himself is
>> unable to see his own data.
>>
>>
>> --
>>
>> Thanks & Regards,
>> Jayavant Ningoji Patil
>> Engineer: System Software
>> Computational Research Laboratories Ltd.
>> Pune-411 004.
>> Maharashtra, India.
>> +91 9923536030.
>>
>>
>
> >The user itself is unable to see its own info.
>
> >[ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com" "(cn=ldap_6)" -h
> server
> >ldap_initialize( ldap://server )
> >filter: (cn=ldap_6)
> >requesting: All userApplication attributes
> ># extended LDIF
> >#
> ># LDAPv3
> ># base <dc=abc,dc=com> with scope subtree
> ># filter: (cn=ldap_6)
> ># requesting: ALL
> >#
>
> ># search result
> >search: 2
> >result: 32 No such object
>
> ># numResponses: 1
>
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
Can you show me your server as well as client side configuration settings?
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
12 years, 11 months
Re: fedora and openldap
by Judith Flo Gaya
Hello ldap,
In fact in my authconfig instruction I have --enableforcelegacy, but
this only works on my f14 clients, rh refuses to accept this option, but
I already set the forcelegacy=yes in my /etc/sysconfig/authconfig.
At the very beginning sssd was a little crazy... but I have learnt to
get rid of it.
How do you set your authconfig system? right now is the only missing
part of the puzzle ;(
On 04/14/2011 07:40 PM, ldap(a)mm.st wrote:
> I came in late on this thread, so disregard if this has already been
> said or is not applicable. Also, we use standard RH packages, so if you
> are building your own, this may not be any use to you.
>
> We have a few RH6 boxes authenticating against our ldap servers. It's
> been awhile, but in addition to the CA certs being copied to the clients
> and the correct perms assigned we had come success enabling legacy mode
> in RH6 when running authconfig to set up the box. If I recall, in
> legacy mode sssd does not run and it uses a more RH5 way of
> authenticating clients. Unfortunately, I don't have a RH6 box in front
> of me, but you can edit /etc/sysconfig/authconfig to set legacy mode.
> Then run your authconfig command to set up the box. Also, look at
> /etc/pam_ldap.conf if you decide to try to authenticate in this manner.
> The settings in there are like they were in /etc/ldap.conf, RH5. Your
> system-auth file looks like ours does as far as I can remember.
>
> Just something else you may want to try if you haven't already.
>
> On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"<jflo(a)imppc.org>
> wrote:
>> Hello,
>>
>> After doing all you suggest with the pki keys I'm stuck in the very same
>> place, the system is able to do ldapsearch but all user auth is not
>> working, I do this in order to configure the auth in the clients
>> # authconfig --disablecachecreds --enableldaps --enableldapauth
>> --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
>> --disablefingerprint --disablewinbind --disablewins --disablesssd
>> --disablesssdauth --disablenis --enablecache --enablelocauthorize
>> --disablemd5 --passalgo=sha512 --updateall
>>
>>
>> The pam.d files look ok:
>>
>> # cat /etc/pam.d/system-auth
>> #%PAM-1.0
>> # This file is auto-generated.
>> # User changes will be destroyed the next time authconfig is run.
>> auth required pam_env.so
>> auth sufficient pam_unix.so nullok try_first_pass
>> auth requisite pam_succeed_if.so uid>= 500 quiet
>> auth sufficient pam_ldap.so use_first_pass
>> auth required pam_deny.so
>>
>> account required pam_unix.so broken_shadow
>> account sufficient pam_localuser.so
>> account sufficient pam_succeed_if.so uid< 500 quiet
>> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
>> account required pam_permit.so
>>
>> password requisite pam_cracklib.so try_first_pass retry=3 type=
>> password sufficient pam_unix.so sha512 shadow nullok
>> try_first_pass use_authtok
>> password sufficient pam_ldap.so use_authtok
>> password required pam_deny.so
>>
>> session optional pam_keyinit.so revoke
>> session required pam_limits.so
>> session [success=1 default=ignore] pam_succeed_if.so service in
>> crond quiet use_uid
>> session required pam_unix.so
>> session optional pam_ldap.so
>>
>> This is the message in ldap server when I do id<ldap_user>
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
>> IP=[::1]:36208 (IP=[::]:636)
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
>> tls_ssf=256 ssf=256
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
>> oid=1">oid=1.3.6.1.4.1.1466.20037
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
>> text=TLS already started
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
>>
>> Aparently is ok but the id is not known
>> Any ideas?
>> Thanks a lot!
>> j
>>
>> On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
>>> Hello Aaron,
>>>
>>> On 04/13/2011 09:07 PM, Aaron Richton wrote:
>>>> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
>>>>
>>>>> I see, I also have those files that you mention... I created my own CA
>>>>> as lots of tutorials explain.. Then I transmitted it to the clients and
>>>>> used it in the ldap.conf file. Do you suggest me to send those to the
>>>>> server and use them instead of the ones I generated with openssl?
>>>>
>>>> Well, you'll need the CA on the client to match the CA that signed the
>>>> server's certificate. In other words...if you generated your own CA for
>>>> both the client and the server, trust issues would be completely
>>>> expected...
>>> I don't know if I understood you or I didn't make myself clear on that
>>> point. I created a CA in the server and the copied the file to the
>>> client, is that wrong?
>>>>
>>>>> What's your server?
>>>>
>>>> OpenLDAP software is on both sides of the equation; it's just that some
>>>> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
>>>> ALL servers are OpenSSL.
>>> I was talking about the operating system, for some reason I think that
>>> having red hat (with openldap compiled using openssl) and clients with
>>> fedora (openldap compiled against moznss) created my problems.
>>> Now that you said that this is your case (I think) then it may be
>>> something related to... I don't know what.
>>>>
>>>>> Well my final problem were not ldapsearch but the user autenticacion.
>>>>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
>>>>> with an ldap user to the machine, I get some TLS negotiation problem ;(
>>>>> That's when I was told that the problem may be caused by the
>>>>> implementation of the ldap client (with moznss support).
>>>>
>>>> Well, when troubleshooting, it's often easiest to look with a narrow
>>>> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
>>>> will probably offer a better debugging platform than an ssh
>>>> implementation? One step at a time...
>>> Yes, I totally agree, that's why I setup my own openldap installation
>>> and only care about ldapsearch working, then when ldapsearch finally
>>> worked, then I start looking at the user auth part, changing passw,
>>> etc.. as this part wasn't working and it appear to be a moznss problem,
>>> I got stuck... until you arrived, I will try what you suggest about
>>> using the pki certs instead of the openssl ones..
>>>
>>> Thanks a lot for the suggestion, hope this finally fix the issue.
>>> j
>>
>> --
>> Judith Flo Gaya
>> Systems Administrator IMPPC
>> e-mail: jflo(a)imppc.org
>> Tel (+34) 93 554-3079
>> Fax (+34) 93 465-1472
>>
>> Institut de Medicina Predictiva i Personalitzada del Càncer
>> Crta Can Ruti, Camí de les Escoles s/n
>> 08916 Badalona, Barcelona,
>> Spain
>> http://www.imppc.org
>>
>>
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo(a)imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org
13 years, 6 months
Re: openldap 2.4.23 hangs
by Howard Chu
rwsmith(a)bislink.net wrote:
>
>
> Hi,
>
>
>
> Not sure if I should post this here or with the CentOS mailing list (I am
> hoping they are monitoring this). I am using a stock CentOS 6.3 32-bit
> installation with
>
>
>
> # rpm -qa | grep openldap
> openldap-devel-2.4.23-26.el6_3.2.i686
> openldap-2.4.23-26.el6_3.2.i686
> openldap-clients-2.4.23-26.el6_3.2.i686
> openldap-servers-2.4.23-26.el6_3.2.i686
>
>
>
> I have a 4-way multi-master sync replication set up on four virtual servers
> using Citrix XenServer 6.2. I am also running Samba 3.5.10 as a PDC on one
> machine and BDC on the other three. All servers are also running sssd-1.8.0
> for the Linux authentication.
>
>
>
> The problem is that one or more of the LDAP servers will hang, usually the one
> that acts as the PDC, since this is hit the hardest and is the more critical
> of the four. Usually but not always the "hang" will trickle to the other
> servers--usually when I am not watching during the middle of the night.
> Fortunately we are not yet in full production.
>
>
>
> Compiling from source is not yet an option. I must use the stock RPMs from
> CentOS per our design guidelines.
>
>
>
> LDAP will appear to hang but what appears to be happening is that only the
> listener becomes busy and will not get out this state. Here is a short pull of
> the logs that I am collecting:
Sounds like this was fixed in 2.4.25, git commit ID
0ae659ad87c64bef938f729e87573ff3ce04bd28 (master),
commit a3f40e5601c0c522f2bda418374fb415bdcbd75c (release).
There was no ITS submitted for this change, so it is not in the CHANGES file.
If you can reproduce the problem with 2.4.32 please submit an ITS for it. I
will note that all of this listener code is targeted for a major rewrite in
OpenLDAP 2.5.
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 STARTTLS
> Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 RESULT oid= err=0 text=
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:44 auth-us slapd[10357]:
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:44 auth-us slapd[10357]: 69r
> Aug 14 20:34:44 auth-us slapd[10357]:
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:54 auth-us slapd[10357]: 39r
> Aug 14 20:34:54 auth-us slapd[10357]:
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: read active on 39
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:54 auth-us slapd[10357]:
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on:
>
> Aug 14 20:35:12 auth-us slapd[10357]: 42r
> Aug 14 20:35:12 auth-us slapd[10357]:
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: read active on 42
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:35:14 auth-us slapd[10357]: 40r
> Aug 14 20:35:14 auth-us slapd[10357]:
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: read active on 40
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
>
>
>
> Every log entry prior to this looks normal in that epoll: listen=7 goes
> between active_threads=0 to busy when a connection comes in, sets up the
> connection, and then goes back to active_threads=0. I have yet to understand
> what is going on to cause it to go into the busy state and never to return
> until I manually stop and restart the slapd process. It does appear however
> that slapd can still process any queries on active connections as noted on
> descriptors 40r and 42r--it just can't process any new connection requests as
> epoll: listen=7 has hung.
>
>
>
> Looking through the archives this problem still appears to be present in a few
> additional later releases but I have not found any thread yet which points to
> a specific solution or patch that fixes this problem. Unless I can point to a
> specific solution and/or patch I won't get approval to do a pull from the
> latest source and compile--I'll have to stick with an hourly cron job that
> stops and restart slapd.
>
>
>
> Thanks,
>
> Bob Smith
>
> --bs
>
>
>
>
>
>
>
>
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 2 months
Re: Security between server and client nodes.
by Raffael Sahli
On 12/02/2011 09:58 AM, Jayavant Patil wrote:
>
>
> On Fri, Dec 2, 2011 at 12:19 PM, Jayavant Patil
> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote:
>
>
>
> On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil
> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>>
> wrote:
>
> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
> >
> >
> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> > >>
> > >>
> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> > >> <jayavant.patil82(a)gmail.com
> <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>
>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>>> wrote:
> > >>
> > >>
> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>
> > <mailto:public@raffaelsahli.com
> <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com
> <mailto:public@raffaelsahli.com>>>> wrote:
> > >> >>Hi
> > >>
> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
> > >> >>Please read the manual
> http://www.openldap.org/doc/admin24/tls.html
> > >> >Ok.
> > >>
> > >> >>And tree security:
> > >> >>On my server, a client user can only see his own object:
> > >> >Are you using simple authentication mechanism?
> > >>
> > >> >>Maybe create a rule like this:
> > >> >>access to filter=(objectClass=
> > >> >>simpleSecurityObject)
> > >> >> by self read
> > >> >> by * none
> > >>
> > >> >I am not getting what the ACL rule specifies. Any
> suggestions?
> > >>
> > >>
> > >> I have two users ldap_6 and ldap_7. I want to
> restrict a user to
> > >> see his own data only.
> > >> In slapd.conf, I specified the rule as follows:
> > >> access to *
> > >> by self write
> > >> by * none
> > >>
> > >> But ldap_6 can see the ldap_7 user entries (or vice
> versa) with
> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> > >>
> > >> Any suggestions?
> > >>
> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com
> <mailto:public@raffaelsahli.com>>> wrote:
> > >Yes, that's exactly the rule I wrote above.
> >
> > >access to filter=(objectClass=
> > >simpleSecurityObject)
> > > by self read
> > > by * none
> >
> >
> > >Maybe you have to change the objectClass to posixAccount,
> or both or
> > >whatever....
> >
> > >access to
> > >filter=(|(objectClass=
> simpleSecurityObject)(objectClass=posixAccount))
> > > by self read
> > > by * none
> >
> >
> > >Just add this rule before the global rule "access to *"
> >
> >
> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
> >
> > >And if you search like this with bind "admin dn", you will
> see every
> > >object....
> > >You have to bind with user ldap_6 and not with root
> > But anyway client user knows the admin dn and
> rootbindpassword. So,
> > with this he will look into all directory information to
> which he is
> > not supposed to do.
> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
> >
> > So, how to avoid this?
> >
>
>
> >>>Why client user knows the admin dn and pw????????
>
> >>Because /etc/ldap.conf file on client contains admin dn and pw.
>
> >>Each user information in the directory contains the
> following entries(here, e.g. ldap_6)
>
>
> >>dn: uid=ldap_6,ou=People,dc=abc,dc=com
> >>uid: ldap_6
> >>cn: ldap_6
> >>sn: ldap_6
> >>mail: ldap_6(a)abc.com <mailto:ldap_6@abc.com>
> >>objectClass: person
> >>objectClass: organizationalPerson
> >>objectClass: inetOrgPerson
> >>objectClass: posixAccount
> >>objectClass: top
> >>objectClass: shadowAccount
> >>objectClass: hostObject
> >>objectClass: simpleSecurityObject
> >>shadowLastChange: 13998
> >>shadowMax: 99999
> >>shadowWarning: 7
> >>loginShell: /bin/bash
> >>uidNumber: 514
> >>gidNumber: 514
> >>homeDirectory: /home/ldap_6
> >>host: *
> >>userPassword::
> e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>
>
> >>So, what should be the ACL rule so that each user can see
> his data only? I tried but not getting the required, even
> >>the user himself is unable to see his own data.
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
> >The user itself is unable to see its own info.
>
> >[ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com"
> "(cn=ldap_6)" -h server
> >ldap_initialize( ldap://server )
> >filter: (cn=ldap_6)
> >requesting: All userApplication attributes
> ># extended LDIF
> >#
> ># LDAPv3
> ># base <dc=abc,dc=com> with scope subtree
> ># filter: (cn=ldap_6)
> ># requesting: ALL
> >#
>
> ># search result
> >search: 2
> >result: 32 No such object
>
> ># numResponses: 1
>
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
> Can you show me your server as well as client side configuration settings?
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
Hmm, I think It's the best to start simple.
Just create two ACL Rules like this in your slapd configuration
#access only own user object and service user under ou=system
access to filter=(objectClass=person)
by self read
by dn.children="ou=system,dc=mydomain,dc=com" read
by * none
#All others are readable to everybody
access to *
by * read
And client config ( It's on Debian! )
NSS (Example configuration):
/etc/libnss-ldap.conf
#LDAP Servers
#------------------------------------
uri ldap://myldapserver:389
base dc=mydomain,dc=com
rootbinddn cn=admin,dc=mydomain,dc=com
#TLS
#------------------------------------
tls_cacertfile /etc/ldap/ssl/cacert.pem
tls_cert /etc/ldap/ssl/cert.pem
tls_key /etc/ldap/ssl/key.pem
ssl start_tls
scope sub
bind_policy soft
#NSS settings
#------------------------------------
nss_base_passwd dc=mydomain,dc=com?sub
nss_base_shadow dc=mydomain,dc=com?sub
nss_base_group dc=mydomain,dc=com?sub
And the bind password is in the file /etc/libnss-ldap.secret (Root
access only!)
And I don't have ldap pam, just kerberos.... But the pam_ldap config is
identic to nss ldap
And for the rest, RTFM!
--
Raffael Sahli
public(a)raffaelsahli.com
Switzerland
12 years, 11 months
Re: CSN too old, ignoring - and therefore not syncing
by Pat Riehecky
On Tue, 2008-12-23 at 11:45 +0000, Gavin Henry wrote:
> Can you post your config somewhere?
allow bind_v2
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/eduperson-200412.schema
include /etc/ldap/schema/hdb.schema
include /etc/ldap/schema/IWU.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload back_monitor
moduleload memberof
moduleload syncprov
moduleload smbk5pwd
tool-threads 2
sizelimit 500
idletimeout 7200
TLSCACertificateFile /etc/ldap/ssl/IWU.crt
TLSCertificateFile /etc/ldap/ssl/ldap.iwu.edu.crt
TLSCertificateKeyFile /etc/ldap/ssl/ldap.iwu.edu.key
TLSVerifyClient allow
localSSF 160
security ssf=1 update_ssf=128 simple_bind=112
sasl-secprops noanonymous
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
backend hdb
database hdb
overlay memberof
overlay smbk5pwd
overlay syncprov
smbk5pwd-enable samba
smbk5pwd-enable krb5
smbk5pwd-must-change 0
syncprov-checkpoint 100 10
syncprov-sessionlog 200
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
suffix "dc=iwu,dc=edu"
rootdn "cn=admin,dc=iwu,dc=edu"
rootpw {redacted}
authz-regexp "uidNumber=0\\\
+gidNumber=.*,cn=peercred,cn=external,cn=auth"
"cn=ldapi,dc=iwu,dc=edu"
authz-regexp "gidNumber=.*\\\
+uidNumber=0,cn=peercred,cn=external,cn=auth"
"cn=ldapi,dc=iwu,dc=edu"
authz-regexp "uid=(.+),cn=.+,cn=auth" "uid=$1,ou=People,dc=iwu,dc=edu"
directory "/var/lib/ldap/"
dbconfig set_cachesize 0 62914560 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
# Make sure to do a nightly slapcat
dbconfig set_flags DB_LOG_AUTOREMOVE
index objectClass eq,pres
index default eq,sub,pres
index mail eq,sub,pres
index sn eq,sub,pres
index cn eq,sub,pres
index displayName eq,sub,pres
index gecos eq,sub,pres
index uid eq,sub,pres
index memberUid eq,sub,pres
index uidNumber eq,pres
index gidNumber eq,pres
index entryCSN eq,pres
index entryUUID eq,pres
index uniqueMember eq,pres
index userPassword eq,pres
index krb5PrincipalName eq,pres
index krb5PrincipalRealm eq,pres
index sambaDomainName eq,pres
index sambaSID eq,pres
index sambaPrimaryGroupSID eq,pres
index sambaSIDList eq,pres
lastmod on
checkpoint 256 15
password-hash {SSHA}
limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited
time.hard=unlimited size.soft=unlimited time.soft=unlimited
limits dn.exact="cn=ldapi,dc=iwu,dc=edu" size.hard=unlimited
time.hard=unlimited size.soft=unlimited time.soft=unlimited
limits dn.exact="cn=sambaadmin,dc=iwu,dc=edu" size.hard=unlimited
time.hard=unlimited size.soft=unlimited time.soft=unlimited
limits dn.exact="cn=mirror,dc=iwu,dc=edu" size.hard=unlimited
time.hard=unlimited size.soft=unlimited time.soft=unlimited
limits dn.exact="cn=freeradius,dc=iwu,dc=edu" size.hard=unlimited
time.hard=unlimited size.soft=unlimited time.soft=unlimited
access to dn.sub="dc=iwu,dc=edu"
by dn.exact="cn=ldapi,dc=iwu,dc=edu" write
by dn.exact="cn=sambaadmin,dc=iwu,dc=edu" write
by dn.exact="cn=mirror,dc=iwu,dc=edu" read
by dn.exact="cn=freeradius,dc=iwu,dc=edu" read
by * break
access to dn.sub="dc=iwu,dc=edu"
attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,krb5Key
by anonymous auth
by self write
by dn.exact="cn=passwordmanager,dc=iwu,dc=edu" write
by users auth
by * break
access to dn.exact="cn=ldapi,dc=iwu,dc=edu" by * none
access to dn.exact="cn=sambaadmin,dc=iwu,dc=edu" by * none
access to dn.exact="cn=mirror,dc=iwu,dc=edu" by * none
access to dn.exact="cn=freeradius,dc=iwu,dc=edu" by * none
access to dn.exact="cn=passwordmanager,dc=iwu,dc=edu" by * none
access to dn.exact="cn=admin,dc=iwu,dc=edu" by * none
access to dn.regex="uid=.*\$,ou=People,dc=iwu,dc=edu" by self read by *
none
access to dn.sub="ou=Computers,dc=iwu,dc=edu" by self read by * none
access to dn.sub="ou=Idmap,dc=iwu,dc=edu" by self read by * none
access to dn.exact="sambaDomainName=IWU.EDU,dc=iwu,dc=edu" by self read
by * none
access to dn.exact="uid=Administrator,ou=People,dc=iwu,dc=edu" by self
read by * none
access to dn.exact="uid=root,ou=People,dc=iwu,dc=edu" by self read by *
none
access to
dn.regex="krb5PrincipalName=.*(a)IWU.EDU,ou=People,dc=iwu,dc=edu" by self
read by * none
access to dn.sub="dc=iwu,dc=edu"
attrs=telephoneNumber,mobileTelephoneNumber,homePostalAddress,streetAddress,physicalDeliveryOfficeName,roomNumber,preferredLanguage,localityName,postOfficeBox,postalCode,stateOrProvinceName
by self write
by users read
by anonymous none
by * break
access to dn.sub="dc=iwu,dc=edu"
attrs=krb5PrincipalName,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,krb5KeyVersionNumber
by self read
by anonymous none
by * break
access to dn.sub="dc=iwu,dc=edu"
attrs=sambaPrimaryGroupSID,sambaSID,sambaAlgorithmicRidBase,sambaNextRid
by * none
access to dn.sub="dc=iwu,dc=edu"
attrs=sambaPwdCanChange,sambaLogonTime,sambaLogoffTime,sambaAcctFlags,sambaPasswordHistory,sambaPwdLastSet,sambaGroupType,sambaPwdMustChange,sambaKickoffTime,sambaLockoutThreshold,sambaForceLogoff,sambaRefuseMachinePwdChange,sambaLockoutObservationWindow,sambaLockoutDuration,sambaMinPwdAge,sambaMaxPwdAge,sambaLogonToChgPwd,sambaPwdHistoryLength,sambaMinPwdLength
by self read
by anonymous none
by * break
access to dn.sub="dc=iwu,dc=edu" by * read
serverID 1
syncrepl rid=2
provider=ldap://ldap2.iwu.edu/
schemachecking=off
searchbase="dc=iwu,dc=edu"
scope=sub
type=refreshAndPersist
binddn="cn=mirror,dc=iwu,dc=edu"
credentials={redacted}
bindmethod=simple
starttls=yes
tls_cert=/etc/ldap/ssl/ldap.iwu.edu.crt
tls_key=/etc/ldap/ssl/ldap.iwu.edu.key
tls_cacert=/etc/ldap/ssl/IWU.crt
tls_reqcert=try
interval=00:00:00:30
retry="15 +"
timeout=1
timelimit=unlimited
sizelimit=unlimited
mirrormode on
###############################
database monitor
limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited
time.hard=unlimited size.soft=unlimited time.soft=unlimited
access to dn.exact="cn=Monitor"
by dn.exact="cn=admin,dc=iwu,dc=edu" read
by * none
access to dn.subtree="cn=Monitor"
by dn.exact="cn=admin,dc=iwu,dc=edu" read
by * none
>
> On 22/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote:
> > Here is the quick and dirty what I am trying to do:
> >
> > ldap1 and ldap2 are supposed to be in MultiMaster. They are time synced
> > to pool.ntp.org and each other (if they drift I would rather they sorta
> > drift together, but pool should be keeping that in check).
> >
> > Right now I am just beating them up to see how 2.4.13 performs. (So far
> > VERY well, minus this little problem)
> >
> > I have a rather small ldif (41 entries) that just wont sync (I'm
> > starting small). Debug gives me
> >
> > ber_scanf fmt (m}) ber:
> > ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62
> > 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30
> > 30 .<rid=001,sid=00
> > 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37
> > 2,csn=2008122217
> > 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30
> > 4721.855904Z#000
> > 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30
> > 000#001#000000
> > do_syncrep2:
> > cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000
> > do_syncrep2: rid=001 CSN too old, ignoring
> > 20081222174721.855904Z#000000#001#000000
> > ldap_msgfree
> >
> > I am not exactly sure how it gotten to be "too old." The ldif I am
> > importing is not the result of a slapcat or anything that would preserve
> > the CSN or UUID attributes (not that syncrepl uses UUID). I am loading
> > one single file with ldapadd which, in my understanding, sets up the CSN
> > and wouldn't let me import one anyway.
> >
> > Each server has no entries until I load the one, so there shouldn't be
> > any weird stale CSNs causing this. They are "sync'ed" almost instantly
> > after the one system is loaded - I just don't have everything.
> >
> > After a sync:
> > ldap1 - slapcat |grep dn: |wc -l = 41
> > ldap2 - slapcat |grep dn: |wc -l = 18
> >
> > Right now I can get them in sync with a slapcat/slapadd, but when the go
> > into production I wont be able to say for certain which one is
> > authoritative. That is the purpose of multi-master....
> >
> > OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux 32 bit
> >
> > Any ideas as to what I can do to stop this from happening?
> >
> > Pat
> >
> >
> >
> >
>
15 years, 10 months
SOLVED - Re: fedora and openldap
by Judith Flo Gaya
Hello,
Finally find out in the pam.d files that the passwd file contained this:
-password optional pam_gnome_keyring.so use_authtok
after removing the use_authtok parameter, the user was able to login,
and in general be found by the system.
Changing the password with the passwd command has to be done using the
pam_password exop option in the pam_ldap.conf, it's not the best but it
works.
Thanks to all for your help,
j
On 04/15/2011 11:23 AM, Judith Flo Gaya wrote:
> Hello ldap,
>
> In fact in my authconfig instruction I have --enableforcelegacy, but
> this only works on my f14 clients, rh refuses to accept this option, but
> I already set the forcelegacy=yes in my /etc/sysconfig/authconfig.
> At the very beginning sssd was a little crazy... but I have learnt to
> get rid of it.
>
> How do you set your authconfig system? right now is the only missing
> part of the puzzle ;(
>
> On 04/14/2011 07:40 PM, ldap(a)mm.st wrote:
>> I came in late on this thread, so disregard if this has already been
>> said or is not applicable. Also, we use standard RH packages, so if you
>> are building your own, this may not be any use to you.
>>
>> We have a few RH6 boxes authenticating against our ldap servers. It's
>> been awhile, but in addition to the CA certs being copied to the clients
>> and the correct perms assigned we had come success enabling legacy mode
>> in RH6 when running authconfig to set up the box. If I recall, in
>> legacy mode sssd does not run and it uses a more RH5 way of
>> authenticating clients. Unfortunately, I don't have a RH6 box in front
>> of me, but you can edit /etc/sysconfig/authconfig to set legacy mode.
>> Then run your authconfig command to set up the box. Also, look at
>> /etc/pam_ldap.conf if you decide to try to authenticate in this manner.
>> The settings in there are like they were in /etc/ldap.conf, RH5. Your
>> system-auth file looks like ours does as far as I can remember.
>>
>> Just something else you may want to try if you haven't already.
>>
>> On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"<jflo(a)imppc.org>
>> wrote:
>>> Hello,
>>>
>>> After doing all you suggest with the pki keys I'm stuck in the very same
>>> place, the system is able to do ldapsearch but all user auth is not
>>> working, I do this in order to configure the auth in the clients
>>> # authconfig --disablecachecreds --enableldaps --enableldapauth
>>> --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
>>> --disablefingerprint --disablewinbind --disablewins --disablesssd
>>> --disablesssdauth --disablenis --enablecache --enablelocauthorize
>>> --disablemd5 --passalgo=sha512 --updateall
>>>
>>>
>>> The pam.d files look ok:
>>>
>>> # cat /etc/pam.d/system-auth
>>> #%PAM-1.0
>>> # This file is auto-generated.
>>> # User changes will be destroyed the next time authconfig is run.
>>> auth required pam_env.so
>>> auth sufficient pam_unix.so nullok try_first_pass
>>> auth requisite pam_succeed_if.so uid>= 500 quiet
>>> auth sufficient pam_ldap.so use_first_pass
>>> auth required pam_deny.so
>>>
>>> account required pam_unix.so broken_shadow
>>> account sufficient pam_localuser.so
>>> account sufficient pam_succeed_if.so uid< 500 quiet
>>> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
>>> account required pam_permit.so
>>>
>>> password requisite pam_cracklib.so try_first_pass retry=3 type=
>>> password sufficient pam_unix.so sha512 shadow nullok
>>> try_first_pass use_authtok
>>> password sufficient pam_ldap.so use_authtok
>>> password required pam_deny.so
>>>
>>> session optional pam_keyinit.so revoke
>>> session required pam_limits.so
>>> session [success=1 default=ignore] pam_succeed_if.so service in
>>> crond quiet use_uid
>>> session required pam_unix.so
>>> session optional pam_ldap.so
>>>
>>> This is the message in ldap server when I do id<ldap_user>
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
>>> IP=[::1]:36208 (IP=[::]:636)
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
>>> tls_ssf=256 ssf=256
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
>>> oid=1">oid=1.3.6.1.4.1.1466.20037
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
>>> text=TLS already started
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
>>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
>>>
>>> Aparently is ok but the id is not known
>>> Any ideas?
>>> Thanks a lot!
>>> j
>>>
>>> On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
>>>> Hello Aaron,
>>>>
>>>> On 04/13/2011 09:07 PM, Aaron Richton wrote:
>>>>> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
>>>>>
>>>>>> I see, I also have those files that you mention... I created my own CA
>>>>>> as lots of tutorials explain.. Then I transmitted it to the clients and
>>>>>> used it in the ldap.conf file. Do you suggest me to send those to the
>>>>>> server and use them instead of the ones I generated with openssl?
>>>>>
>>>>> Well, you'll need the CA on the client to match the CA that signed the
>>>>> server's certificate. In other words...if you generated your own CA for
>>>>> both the client and the server, trust issues would be completely
>>>>> expected...
>>>> I don't know if I understood you or I didn't make myself clear on that
>>>> point. I created a CA in the server and the copied the file to the
>>>> client, is that wrong?
>>>>>
>>>>>> What's your server?
>>>>>
>>>>> OpenLDAP software is on both sides of the equation; it's just that some
>>>>> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
>>>>> ALL servers are OpenSSL.
>>>> I was talking about the operating system, for some reason I think that
>>>> having red hat (with openldap compiled using openssl) and clients with
>>>> fedora (openldap compiled against moznss) created my problems.
>>>> Now that you said that this is your case (I think) then it may be
>>>> something related to... I don't know what.
>>>>>
>>>>>> Well my final problem were not ldapsearch but the user autenticacion.
>>>>>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
>>>>>> with an ldap user to the machine, I get some TLS negotiation problem ;(
>>>>>> That's when I was told that the problem may be caused by the
>>>>>> implementation of the ldap client (with moznss support).
>>>>>
>>>>> Well, when troubleshooting, it's often easiest to look with a narrow
>>>>> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
>>>>> will probably offer a better debugging platform than an ssh
>>>>> implementation? One step at a time...
>>>> Yes, I totally agree, that's why I setup my own openldap installation
>>>> and only care about ldapsearch working, then when ldapsearch finally
>>>> worked, then I start looking at the user auth part, changing passw,
>>>> etc.. as this part wasn't working and it appear to be a moznss problem,
>>>> I got stuck... until you arrived, I will try what you suggest about
>>>> using the pki certs instead of the openssl ones..
>>>>
>>>> Thanks a lot for the suggestion, hope this finally fix the issue.
>>>> j
>>>
>>> --
>>> Judith Flo Gaya
>>> Systems Administrator IMPPC
>>> e-mail: jflo(a)imppc.org
>>> Tel (+34) 93 554-3079
>>> Fax (+34) 93 465-1472
>>>
>>> Institut de Medicina Predictiva i Personalitzada del Càncer
>>> Crta Can Ruti, Camí de les Escoles s/n
>>> 08916 Badalona, Barcelona,
>>> Spain
>>> http://www.imppc.org
>>>
>>>
>
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo(a)imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org
13 years, 6 months
Re: OPENLDAP SYNCREPL
by Howard Chu
Borresen, John - 0442 - MITLL wrote:
> Thanks, Howard;
>
> In hindsight, if my config looks jumbled, it is...that's what I get for
> doing little things in a quasi-blind attempt at solving issues.
Quanah's followup was correct: you have the consumer configured for
delta-syncrepl but you're missing the provider on your cn=accesslog database.
See the Admin Guide section 18.3.2.
http://www.openldap.org/doc/admin24/replication.html#Configuring%20the%20di…
> *******Here is the output of slapcat on the Provider:**********
>
> # slapcat -s olcDatabase=\{1}bdb,cn=config
> dn: olcDatabase={1}bdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcBdbConfig
> olcSuffix: dc=group42,dc=ldap
> olcAddContentAcl: FALSE
> olcLastMod: TRUE
> olcMaxDerefDepth: 15
> olcReadOnly: FALSE
> olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
> olcRootPW:: ***************
> olcSyncUseSubentry: FALSE
> olcMonitoring: TRUE
> olcDbDirectory: /var/lib/ldap_db/openldap-data
> olcDbCacheSize: 1000
> olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4
> 2007/1
> 2/18 11:53:27 ghenry Exp $
> olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB
> databas
> es.
> olcDbConfig: {2}#
> olcDbConfig: {3}# See the Oracle Berkeley DB documentation
> olcDbConfig: {4}#
> <http://www.oracle.com/technology/documentation/berkeley-d
> b/db/ref/env/db_config.html>
> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
> olcDbConfig: {6}#
> olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
> olcDbConfig::
> ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
> PTI+
> olcDbConfig: {9}# in particular:
> olcDbConfig: {10}#<http://www.openldap.org/faq/index.cgi?file=1075>
> olcDbConfig: {11}
> olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon
> re
> building
> olcDbConfig: {13}# the DB environment.
> olcDbConfig: {14}
> olcDbConfig: {15}# one 0.25 GB cache
> olcDbConfig: {16}set_cachesize 0 268435456 1
> olcDbConfig: {17}
> olcDbConfig: {18}# Data Directory
> olcDbConfig: {19}#set_data_dir db
> olcDbConfig: {20}
> olcDbConfig: {21}# Transaction Log settings
> olcDbConfig: {22}set_lg_regionmax 262144
> olcDbConfig: {23}set_lg_bsize 2097152
> olcDbConfig: {24}#set_lg_dir logs
> olcDbConfig: {25}
> olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for
> "qui
> ck"
> olcDbConfig::
> ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
> aXIgLXEgb3B0aW9uKS4g
> olcDbNoSync: FALSE
> olcDbDirtyRead: FALSE
> olcDbIDLcacheSize: 0
> olcDbIndex: objectClass eq
> olcDbIndex: sn eq,sub
> olcDbIndex: mail eq,sub
> olcDbIndex: departmentNumber eq
> olcDbIndex: cn,uid eq,sub
> olcDbIndex: uidNumber eq
> olcDbIndex: entryCSN eq
> olcDbIndex: entryUUID eq
> olcDbIndex: ipHostNumber eq
> olcDbIndex: gidNumber,memberUID eq
> olcDbLinearIndex: FALSE
> olcDbMode: 0600
> olcDbShmKey: 0
> olcDbCacheFree: 1
> olcDbDNcacheSize: 0
> structuralObjectClass: olcBdbConfig
> entryUUID: 101e6d86-dd1c-4eaa-a26e-d7e201a727f8
> creatorsName: cn=config
> createTimestamp: 20111219143532Z
> olcDbSearchStack: 32
> olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by
> anonymo
> us auth by * none
> olcAccess: {1} to * by * read
> olcDatabase: {1}bdb
> olcLimits: {0}dn.exact="cn=ldapadmin,dc=group42,dc=ldap" size=unlimited
> time=u
> nlimited
> entryCSN: 20120313163732.658240Z#000000#001#000000
> modifiersName: cn=admin,cn=config
> modifyTimestamp: 20120313163732Z
>
> dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: {0}syncprov
> olcSpNoPresent: TRUE
> structuralObjectClass: olcSyncProvConfig
> entryUUID: 8572b589-f594-44a6-91fe-0de741afbcca
> creatorsName: cn=admin,cn=config
> createTimestamp: 20120224171809Z
> olcSpReloadHint: TRUE
> olcSpCheckpoint: 1000 60
> entryCSN: 20120312145000.123929Z#000000#001#000000
> modifiersName: cn=admin,cn=config
> modifyTimestamp: 20120312145000Z
>
> dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcAccessLogConfig
> olcOverlay: {1}accesslog
> olcAccessLogDB: cn=accesslog
> olcAccessLogOps: writes
> olcAccessLogPurge: 07+00:00 01+00:00
> olcAccessLogSuccess: TRUE
> structuralObjectClass: olcAccessLogConfig
> entryUUID: eea1e438-6385-4660-807b-bb270eb4843a
> creatorsName: cn=admin,cn=config
> createTimestamp: 20120229161649Z
> entryCSN: 20120229161649.880441Z#000000#000#000000
> modifiersName: cn=admin,cn=config
> modifyTimestamp: 20120229161649Z
>
> # slapcat -s olcDatabase=\{2}bdb,cn=config
> dn: olcDatabase={2}bdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcBdbConfig
> olcDbDirectory: /var/lib/ldap_db/accesslog
> olcSuffix: cn=accesslog
> olcDbIndex: default eq
> olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
> structuralObjectClass: olcBdbConfig
> entryUUID: 446c6c64-a899-4f37-9498-cb4a349d3b48
> creatorsName: cn=admin,cn=config
> createTimestamp: 20120229153826Z
> olcLimits: {0}dn.exact="cn=ldapadmin,dc=group42,dc=ldap" time.soft=unlimited
> t
> ime.hard=unlimited size.soft=unlimited size.hard=unlimited
> olcDatabase: {2}bdb
> entryCSN: 20120313143637.046410Z#000000#001#000000
> modifiersName: cn=config
> modifyTimestamp: 20120313143637Z
>
>
>
>
> ################################################
> ***Here is the output of slapcat from the Consumer***
> # slapcat -s olcDatabase=\{2}bdb,cn=config
> dn: olcDatabase={2}bdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcBdbConfig
> olcSuffix: dc=group42,dc=ldap
> olcAddContentAcl: FALSE
> olcLastMod: TRUE
> olcMaxDerefDepth: 15
> olcReadOnly: FALSE
> olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
> olcRootPW:: ***************
> olcSyncUseSubentry: FALSE
> olcMonitoring: TRUE
> olcDbDirectory: /var/lib/ldap_db/openldap-data
> olcDbCacheSize: 1000
> olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.1.2.4
> 2007/1
> 2/18 11:51:46 ghenry Exp $
> olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB
> databas
> es.
> olcDbConfig: {2}#
> olcDbConfig: {3}# See the Oracle Berkeley DB documentation
> olcDbConfig: {4}#
> <http://www.oracle.com/technology/documentation/berkeley-d
> b/db/ref/env/db_config.html>
> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
> olcDbConfig: {6}#
> olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
> olcDbConfig::
> ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
> PTI+
> olcDbConfig: {9}# in particular:
> olcDbConfig: {10}#<http://www.openldap.org/faq/index.cgi?file=1075>
> olcDbConfig: {11}
> olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon
> re
> building
> olcDbConfig: {13}# the DB environment.
> olcDbConfig: {14}
> olcDbConfig: {15}# one 0.25 GB cache
> olcDbConfig: {16}set_cachesize 0 268435456 1
> olcDbConfig: {17}
> olcDbConfig: {18}# Data Directory
> olcDbConfig: {19}#set_data_dir db
> olcDbConfig: {20}
> olcDbConfig: {21}# Transaction Log settings
> olcDbConfig: {22}set_lg_regionmax 262144
> olcDbConfig: {23}set_lg_bsize 2097152
> olcDbConfig: {24}#set_lg_dir logs
> olcDbConfig: {25}
> olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for
> "qui
> ck"
> olcDbConfig::
> ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
> aXIgLXEgb3B0aW9uKS4g
> olcDbNoSync: FALSE
> olcDbDirtyRead: FALSE
> olcDbIDLcacheSize: 0
> olcDbIndex: objectClass eq
> olcDbIndex: cn,uid eq,sub
> olcDbIndex: sn eq,sub
> olcDbIndex: mail eq,sub
> olcDbIndex: departmentNumber eq
> olcDbIndex: entryCSN eq
> olcDbIndex: entryUUID eq
> olcDbIndex: uidNumber eq
> olcDbIndex: gidNumber eq
> olcDbLinearIndex: FALSE
> olcDbMode: 0600
> olcDbSearchStack: 16
> olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by
> anonymo
> us auth by * none
> olcAccess: {1} to * by * read
> olcDbShmKey: 0
> olcDbCacheFree: 1
> olcDbDNcacheSize: 0
> structuralObjectClass: olcBdbConfig
> entryUUID: e6971058-e0f0-4160-aaca-a18b24d22008
> creatorsName: cn=config
> createTimestamp: 20120229205835Z
> olcDatabase: {2}bdb
> olcUpdateRef: ldaps://gp42-admin2.group42.ldap:636
> olcMirrorMode: TRUE
> olcSyncrepl: {0}rid=1 provider=ldaps://gp42-admin2.group42.ldap:636
> bindmethod
> =simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=*********
> interva
> l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog"
> schemach
> ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)"
> attrs=
> "*,+" syncdata=accesslog starttls=no
> tls_cacertdir=/usr/local/openldap-2.4.23
> /etc/openldap/cacerts
> entryCSN: 20120313150609.224840Z#000000#000#000000
> modifiersName: cn=admin,cn=config
> modifyTimestamp: 20120313150609Z
>
> dn: olcOverlay={0}memberof,olcDatabase={2}bdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcMemberOf
> olcOverlay: {0}memberof
> structuralObjectClass: olcMemberOf
> entryUUID: 363ad8ed-872c-4fff-99c1-4f73d3e8055d
> creatorsName: cn=admin,cn=config
> createTimestamp: 20120302121345Z
> entryCSN: 20120302121345.220702Z#000000#000#000000
> modifiersName: cn=admin,cn=config
> modifyTimestamp: 20120302121345Z
>
> dn: olcOverlay={1}syncprov,olcDatabase={2}bdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: {1}syncprov
> olcSpNoPresent: TRUE
> structuralObjectClass: olcSyncProvConfig
> entryUUID: 69ca3f6a-1ac4-45f9-88ca-eb7f67ca7b63
> creatorsName: cn=admin,cn=config
> createTimestamp: 20120302141557Z
> entryCSN: 20120302141557.545770Z#000000#000#000000
> modifiersName: cn=admin,cn=config
> modifyTimestamp: 20120302141557Z
>
> I know that the two systems are communicating, at least, at the client level
> and attempting to at the slapd level. As stated earlier, the only error I'm
> seeing consistently on the Consumer is:
> do_syncrep2: rid=001 got search entry without Sync State control
> do_syncrepl: rid=001 rc -1 retrying
>
> David Borresen
> ph: 781-981-2954
> email: john.d.borresen(a)ll.mit.edu
>
>
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: Tuesday, March 13, 2012 2:01 PM
> To: Borresen, John - 0442 - MITLL
> Cc: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: Re: OPENLDAP SYNCREPL
>
> Borresen, John - 0442 - MITLL wrote:
>> Thanks, Quanah;
>>
>> As requested:
>
> That was clearly not the problem; if the syncprov module was missing your
> config would have caused slapd to fail to start. Also it was clearly present
>
> since you had it updating the contextCSN in your shutdown log. Quanah, you
> should have already seen that and not sent him on a wild goose chase.
>
> And, one more time: DO NOT DIRECTLY ACCESS THE FILES IN THE CONFIG
> DIRECTORY.
>
> Use the database administration tools. For your previous case, you should
> have
> simply used:
> slapcat -s olcDatabase=\{1\}bdb,cn=config
>
> Make sure the consumer is talking to the server you think it is. Show slapd
> -d7 output from the provider while the consumer is trying to connect.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 8 months
Re: fedora and openldap
by ldap＠mm.st
Have you tried to use the "tls_reqcert never" directive in nslcd.conf
(may not apply in your case ?). I wouldn't run this way, just for
troubleshooting. Also, in nslcd.conf did I see that you changed "ssl
start_tls" to something else. We use "ssl start_tls" in our RH6 boxes.
Also, in nslcd.conf we found success using these directives for RH6 (RH5
uses "nss_base_passwd" type directives):
scope one
base group ou=Group,o=example.com
base passwd ou=People,o=example.com
base shadow ou=People,o=example.com
Finally, I'm sure you checked it but with the error below, you should
verify you do not have "uri ldaps://ldap.server.com/" (trailing slash
important) in any of your client config files since you are using
start_tls..
On Fri, 15 Apr 2011 11:23 +0200, "Judith Flo Gaya" <jflo(a)imppc.org>
wrote:
> Hello ldap,
>
> In fact in my authconfig instruction I have --enableforcelegacy, but
> this only works on my f14 clients, rh refuses to accept this option, but
> I already set the forcelegacy=yes in my /etc/sysconfig/authconfig.
> At the very beginning sssd was a little crazy... but I have learnt to
> get rid of it.
>
> How do you set your authconfig system? right now is the only missing
> part of the puzzle ;(
>
> On 04/14/2011 07:40 PM, ldap(a)mm.st wrote:
> > I came in late on this thread, so disregard if this has already been
> > said or is not applicable. Also, we use standard RH packages, so if you
> > are building your own, this may not be any use to you.
> >
> > We have a few RH6 boxes authenticating against our ldap servers. It's
> > been awhile, but in addition to the CA certs being copied to the clients
> > and the correct perms assigned we had come success enabling legacy mode
> > in RH6 when running authconfig to set up the box. If I recall, in
> > legacy mode sssd does not run and it uses a more RH5 way of
> > authenticating clients. Unfortunately, I don't have a RH6 box in front
> > of me, but you can edit /etc/sysconfig/authconfig to set legacy mode.
> > Then run your authconfig command to set up the box. Also, look at
> > /etc/pam_ldap.conf if you decide to try to authenticate in this manner.
> > The settings in there are like they were in /etc/ldap.conf, RH5. Your
> > system-auth file looks like ours does as far as I can remember.
> >
> > Just something else you may want to try if you haven't already.
> >
> > On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"<jflo(a)imppc.org>
> > wrote:
> >> Hello,
> >>
> >> After doing all you suggest with the pki keys I'm stuck in the very same
> >> place, the system is able to do ldapsearch but all user auth is not
> >> working, I do this in order to configure the auth in the clients
> >> # authconfig --disablecachecreds --enableldaps --enableldapauth
> >> --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
> >> --disablefingerprint --disablewinbind --disablewins --disablesssd
> >> --disablesssdauth --disablenis --enablecache --enablelocauthorize
> >> --disablemd5 --passalgo=sha512 --updateall
> >>
> >>
> >> The pam.d files look ok:
> >>
> >> # cat /etc/pam.d/system-auth
> >> #%PAM-1.0
> >> # This file is auto-generated.
> >> # User changes will be destroyed the next time authconfig is run.
> >> auth required pam_env.so
> >> auth sufficient pam_unix.so nullok try_first_pass
> >> auth requisite pam_succeed_if.so uid>= 500 quiet
> >> auth sufficient pam_ldap.so use_first_pass
> >> auth required pam_deny.so
> >>
> >> account required pam_unix.so broken_shadow
> >> account sufficient pam_localuser.so
> >> account sufficient pam_succeed_if.so uid< 500 quiet
> >> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
> >> account required pam_permit.so
> >>
> >> password requisite pam_cracklib.so try_first_pass retry=3 type=
> >> password sufficient pam_unix.so sha512 shadow nullok
> >> try_first_pass use_authtok
> >> password sufficient pam_ldap.so use_authtok
> >> password required pam_deny.so
> >>
> >> session optional pam_keyinit.so revoke
> >> session required pam_limits.so
> >> session [success=1 default=ignore] pam_succeed_if.so service in
> >> crond quiet use_uid
> >> session required pam_unix.so
> >> session optional pam_ldap.so
> >>
> >> This is the message in ldap server when I do id<ldap_user>
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
> >> IP=[::1]:36208 (IP=[::]:636)
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
> >> tls_ssf=256 ssf=256
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
> >> oid=1">oid=1.3.6.1.4.1.1466.20037
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
> >> text=TLS already started
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
> >> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
> >>
> >> Aparently is ok but the id is not known
> >> Any ideas?
> >> Thanks a lot!
> >> j
> >>
> >> On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
> >>> Hello Aaron,
> >>>
> >>> On 04/13/2011 09:07 PM, Aaron Richton wrote:
> >>>> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
> >>>>
> >>>>> I see, I also have those files that you mention... I created my own CA
> >>>>> as lots of tutorials explain.. Then I transmitted it to the clients and
> >>>>> used it in the ldap.conf file. Do you suggest me to send those to the
> >>>>> server and use them instead of the ones I generated with openssl?
> >>>>
> >>>> Well, you'll need the CA on the client to match the CA that signed the
> >>>> server's certificate. In other words...if you generated your own CA for
> >>>> both the client and the server, trust issues would be completely
> >>>> expected...
> >>> I don't know if I understood you or I didn't make myself clear on that
> >>> point. I created a CA in the server and the copied the file to the
> >>> client, is that wrong?
> >>>>
> >>>>> What's your server?
> >>>>
> >>>> OpenLDAP software is on both sides of the equation; it's just that some
> >>>> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
> >>>> ALL servers are OpenSSL.
> >>> I was talking about the operating system, for some reason I think that
> >>> having red hat (with openldap compiled using openssl) and clients with
> >>> fedora (openldap compiled against moznss) created my problems.
> >>> Now that you said that this is your case (I think) then it may be
> >>> something related to... I don't know what.
> >>>>
> >>>>> Well my final problem were not ldapsearch but the user autenticacion.
> >>>>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
> >>>>> with an ldap user to the machine, I get some TLS negotiation problem ;(
> >>>>> That's when I was told that the problem may be caused by the
> >>>>> implementation of the ldap client (with moznss support).
> >>>>
> >>>> Well, when troubleshooting, it's often easiest to look with a narrow
> >>>> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
> >>>> will probably offer a better debugging platform than an ssh
> >>>> implementation? One step at a time...
> >>> Yes, I totally agree, that's why I setup my own openldap installation
> >>> and only care about ldapsearch working, then when ldapsearch finally
> >>> worked, then I start looking at the user auth part, changing passw,
> >>> etc.. as this part wasn't working and it appear to be a moznss problem,
> >>> I got stuck... until you arrived, I will try what you suggest about
> >>> using the pki certs instead of the openssl ones..
> >>>
> >>> Thanks a lot for the suggestion, hope this finally fix the issue.
> >>> j
> >>
> >> --
> >> Judith Flo Gaya
> >> Systems Administrator IMPPC
> >> e-mail: jflo(a)imppc.org
> >> Tel (+34) 93 554-3079
> >> Fax (+34) 93 465-1472
> >>
> >> Institut de Medicina Predictiva i Personalitzada del Càncer
> >> Crta Can Ruti, Camí de les Escoles s/n
> >> 08916 Badalona, Barcelona,
> >> Spain
> >> http://www.imppc.org
> >>
> >>
>
> --
> Judith Flo Gaya
> Systems Administrator IMPPC
> e-mail: jflo(a)imppc.org
> Tel (+34) 93 554-3079
> Fax (+34) 93 465-1472
>
> Institut de Medicina Predictiva i Personalitzada del Càncer
> Crta Can Ruti, Camí de les Escoles s/n
> 08916 Badalona, Barcelona,
> Spain
> http://www.imppc.org
>
13 years, 6 months