Re: restrict host login based on group
Hi all, I'm stuck in the same issue as Serge Fonville. I have created new Auxiliary objectclass 'testobj' with 'host' attribute added it to the ou=Groups.Then created 2 entries under Groups as below assigned members to those groups. dn: cn=qagroup,ou=Groups,dc=test,dc=com cn: qagroup gidNumber: 4 objectClass: posixGroup objectClass: testobj host: x15f12.test.com memberUid: uid=ldap1,ou=Users,dc=test,dc=com memberUid: uid=ldap2,ou=Users,dc=test,dc=com dn: cn=admin,ou=Groups,dc=test,dc=com cn: admin gidNumber: 0 objectClass: posixGroup objectClass: testobj host: x15ubuntu.test.com memberUid: uid=ldap3,ou=Users,dc=test,dc=com memberUid: uid=ldap4,ou=Users,dc=test,dc=com Now *which parameter in ldap.conf or any other files I host machine should I modify and how,* so that members from qagroup or admin groups only get access to host mentioned in their respective attributes ?? Thanks in advance Shamika 2009/12/3 Adam Hough a...@gradientzero.com Or you can create your own Aux. object class that includes the host attribute then you just have to modify the ldap.conf for the machine to restrict user authentication. - Adam On Thu, 2009-12-03 at 10:48 -0300, Jarbas Peixoto Júnior wrote: If you are using ssh and pam can be done like this: # tail /etc/ssh/sshd_config # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes # Restringir acesso ao grupo local 'suporte' e a grupos LDAP AllowGroups suporte SSH UDSL where SSH UDSL is a Group in LDAP, and suporte is a local group. 2009/12/3 Serge Fonville serge.fonvi...@gmail.com: Hi, While setting up an LDAP server. I noticed that it is not possible to add a host attribute to a posixGroup. Is there a way to limit a user what host they can logon to based on their group membership? Thanks in advance Regards, Serge Fonville -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
gidNumber attribute inside group member
Hi all, I need some clarification regarding how permissions of members are taken care when they login to a client machine. As I understand gidNumber that I give while creating group entry(like gidNumber 4 for qagroup, which refers to gid of adm group on a linux machine /etc/group), so permissions of that group are assigned to members of qagroup i.e. ldap1 ldap2 when they login to any client. Is that correct? It is confusing because, members ldap1 ldap2 belong to posixAccount objectclass which also requires gidNumber as required attribute. So does gidNumber values mentioned in member's entry get overwritten by gidNumber attribute inside their group i.e qagroup? What about the case where single member is added to multiple groups? what permissions does the member get when he logs on to particular machine? ldif input: dn: uid=ldap1,ou=Users,dc=test,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person homeDirectory: /home/ldap1 loginShell: /bin/bash cn: ldap1 uidNumber: 1 gidNumber: 500 = sn: ldap1 mobile: 98787 physicalDeliveryOfficeName: ravi userPassword: ldap1 uid: ldap1 dn: cn=qagroup,ou=Groups,dc=test,dc=com cn: qagroup gidNumber: 4 === objectClass: posixGroup memberUid: uid=ldap1,ou=Users,dc=test,dc=com memberUid: uid=ldap2,ou=Users,dc=test,dc=com Thanks in advance Shamika
Re: Authentication failed with ldaps configuration
Message initial De: Zdenek Styblik sty...@turnovfree.net À: smain...@free.fr Cc: openldap-technical@openldap.org Sujet: Re: Authentication failed with ldaps configuration Date: Thu, 03 Dec 2009 17:03:32 +0100 smain...@free.fr wrote: - Mail Original - De: Zdenek Styblik sty...@turnovfree.net À: smain...@free.fr Cc: openldap-technical@openldap.org Envoyé: Mercredi 2 Décembre 2009 16h37:01 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: Authentication failed with ldaps configuration smain...@free.fr wrote: Hi everyone, I configured my ldap server (debian lenny) to listen on port 636 (ldaps) but it doesn't seems to work when issuing a remote connexion. Perhaps i did a mistake when generating the certificates ? When i try to browse the ldap server from a remote server i get the following message : -- r...@vmtest:~# ldapsearch -d 1 -Wx -H ldaps://ldapserver.domain.tld -D cn=admin,dc=domain,dc=tld ldap_url_parse_ext(ldaps://ldapserver.domain.tld) ldap_create ldap_url_parse_ext(ldaps://ldapserver.domain.tld:636/??base) Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldapserver.domain.tld:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.10.48.40:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: peer cert untrusted or revoked (0x42) ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) --- I generated the certificates with the following command : # openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650 --- Then i tried the connexion : openssl s_client -connect ldapserver.domain.tld:636 -showcerts CONNECTED(0003) depth=0 /C=FR/ST=Some-State/L=Paris/O=firm/CN=ldapserver.domain.tld verify error:num=18:self signed certificate verify return:1 depth=0 /C=FR/ST=Some-State/L=Paris/O=firm/CN=ldapserver.domain.tld verify return:1 --- Certificate chain 0 s:/C=FR/ST=Some-State/L=Paris/O=firm/CN=ldapserver.domain.tld i:/C=FR/ST=Some-State/L=Paris/O=firm/CN=ldapserver.domain.tld -BEGIN CERTIFICATE- MIIDDTCCAnagAwIBAgIJAM7IwuTIzhwqMA0GCSqGSIb3DQEBBQUAMGMxCzAJBgNV BAYTAkZSMRMwEQYDVQQIEwpTb21lLVN0YXRlMQ4wDAYDVQQHEwVQYXJpczELMAkG A1UEChMCQlQxIjAgBgNVBAMTGWlwb2MwMS5pcG9jLmJ0c2VydmljZXMuZnIwHhcN MDkxMTI0MTUwMTUxWhcNMTkxMTIyMTUwMTUxWjBjMQswCQYDVQQGEwJGUjETMBEG A1UECBMKU29tZS1TdGF0ZTEOMAwGA1UEBxMFUGFyaXMxCzAJBgNVBAoTAkJUMSIw IAYDVQQDExlpcG9jMDEuaXBvYy5idHNlcnZpY2VzLmZyMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCm5FrQ3dN1Jkxj2SZsPr+vkYDlwVnvqDCxnAs3O5NJ/1uY F9/mwsCVdAnp04Eywo3BCbvP6tlzsF3JbAlqMLTb85ZTHOqRQncXGfVZ7bMnR071 tQ70/b3vF/TuMYiOU7vXf2h863aRi11tT9xHD17wFfFaXBtRIIOioc3UpJWWPwID AQABo4HIMIHFMB0GA1UdDgQWBBREqX/HQEzU5TCDrBsbttUxa44fnDCBlQYDVR0j BIGNMIGKgBREqX/HQEzU5TCDrBsbttUxa44fnKFnpGUwYzELMAkGA1UEBhMCRlIx EzARBgNVBAgTClNvbWUtU3RhdGUxDjAMBgNVBAcTBVBhcmlzMQswCQYDVQQKEwJC VDEiMCAGA1UEAxMZaXBvYzAxLmlwb2MuYnRzZXJ2aWNlcy5mcoIJAM7IwuTIzhwq MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAd0Le1JyJF8zBs0RYvEn7 c1nhVbsdD8FDBTa4IaNvkbIt8al6G7bBpfyDxcMVtgFc8zHt/+sYfTxWuHh7m+b1 yjJtD9vMjIigbaZq4VJOz11JEWsQHc8wo3So+G+CelTz4HXPoGh5vqRtTkupjedz 0DDsA1jd9F4KpYSOkzxosdc= -END CERTIFICATE- --- Server certificate subject=/C=FR/ST=Some-State/L=Paris/O=firm/CN=ldapserver.domain.tld issuer=/C=FR/ST=Some-State/L=Paris/O=firm/CN=ldapserver.domain.tld --- No client certificate CA names sent --- SSL handshake has read 1107 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: AES256-SHA Session-ID: 9EF5F2D4FD72A0D1161C8334537F1ADF60C8B790A3F699B6DC52557E3C95D427 Session-ID-ctx: Master-Key: 015D50D6D93F502E37EDB577691F05D157E80A439A2B129B370EEA24E651E828A172E43B3F6D29174BF33B96193202F0 Key-Arg : None Start Time: 1259761586 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- --
Re: gidNumber attribute inside group member
On 04/12/09 11:25, Shamika Joshi wrote: Hi all, I need some clarification regarding how permissions of members are taken care when they login to a client machine. As I understand gidNumber that I give while creating group entry(like gidNumber 4 for qagroup, which refers to gid of adm group on a linux machine /etc/group), so permissions of that group are assigned to members of qagroup i.e. ldap1 ldap2 when they login to any client. Is that correct? It is confusing because, members ldap1 ldap2 belong to posixAccount objectclass which also requires gidNumber as required attribute. So does gidNumber values mentioned in member's entry get overwritten by gidNumber attribute inside their group i.e qagroup? What about the case where single member is added to multiple groups? what permissions does the member get when he logs on to particular machine? Hi, The gidNumber of a group is it's unique identifier, in the same way that a uid is the unique identifier of a user. On a UNIX system, file permissions are usually stored with uids and gids, not user- and group- names. So, each group had a gidNumber to uniquely identify it. And each user has a uidNumber to uniquely identify it. And, each user has a primary group - this is their main group. This representation in LDAP objects just mirrors that on a UNIX system: if you look at /etc/passwd, you'll see that one of the fields is a GID. If you run the command id, it's output includes user's UID, main GID and a list of other groups the user is a member of. So, yes, all members of a group with gid 4 have the permissions granted to that group. Each user also has the permissions of his main group. Hope this helps, Jonathan -- -- Jonathan Clarke - jonat...@phillipoux.net -- Ldap Synchronization Connector (LSC) - http://lsc-project.org --
Re: bootstrapping mirrormode
Quanah Gibson-Mount wrote: --On Friday, December 04, 2009 1:12 PM +0100 Peter Mogensen a...@mutex.dk wrote: In general it seems server-2 won't find changes to server-1 made while server-2 is down... which kinda defeats the purpose of mirrormode. What openldap release are you using for this testing? I've quite lost track. 2.4.20 (on debian Lenny) same results with both DB4.6 and DB4.8 /Peter
Re: Two contextCSNs
Hallvard B Furuseth wrote:
Peter Mogensen writes:
I'm trying to understand why changes made to SID 1 in my mirror set
while SID 2 is down does not get propagated to SID 2 when it comes up.
Maybe your mirror is configured with refreshAndPersist mode and you have
not specified a retry interval? Then thed default is 1 hour, according
to the slapd.conf manpage.
No. retry is 60 + (1 minute from what I read).
Since no one has complained against the 8 step procedure I posted, I
will assume that it is the correct way to load an huge LDIF into an
empty mirrormode setup.
So since, it's not the procedure, it must be either my configuration or
a bug. I'll assume it's my configuration though I suspect this message
is about the same problem:
http://www.openldap.org/lists/openldap-software/200911/msg00058.html
So here's my configuration in a step-by-step sequence. I do:
* First install openldap 2.4.20 / db 4.8.24 on two debian Lenny systems.
* Set /etc/ldap/slapd.conf to this:
===
gentlehup on
pidfile /var/run/slapd/slapd.pid
argsfile/var/run/slapd/slapd.args
loglevelnone
tool-threads 8
# Modules
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload syncprov
# Schemas
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
# Limits
disallow bind_anon
idletimeout 120
sizelimit 2000
# TLS/Auth
TLSCACertificateFile/etc/ldap/ssl/ca.crt
TLSCertificateFile /etc/ldap/ssl/server.crt
TLSCertificateKeyFile /etc/ldap/ssl/server.nopass.key
TLSCipherSuite NULL-SHA
# Allow root to configure slapd via ldapi:///
TLSVerifyClient demand
authz-regexp
gidNumber=0\\+uidNumber=0,cn=peercred,cn=external,cn=auth
cn=config
authz-regexp
email=r...@example.com,cn=config,ou=dev,o=example.com,st=Denmark,c=DK
cn=config
# Mirror mode
serverID 1
database config
limits dn.exact=cn=config
time.soft=unlimited
time.hard=unlimited
size.soft=unlimited
size.hard=unlimited
syncrepl rid=1
provider=ldaps://server1.example.com:636/
searchbase=cn=config
type=refreshAndPersist
retry=60 +
scope=sub
schemachecking=on
bindmethod=sasl
binddn=cn=config
saslmech=EXTERNAL
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite=NULL-SHA
syncrepl rid=2
provider=ldaps://server2.example.com:636/
searchbase=cn=config
type=refreshAndPersist
retry=60 +
scope=sub
schemachecking=on
bindmethod=sasl
binddn=cn=config
saslmech=EXTERNAL
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite=NULL-SHA
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncprov-reloadhint TRUE
mirrormode on
=
* Then, I run slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d
to convert the above to a cn=config based setup.
* Then I start slapd on both servers.
$ /usr/sbin/slapd -h ldapi:/// ldaps://server1.example.com:636/ \
ldap://server1.example.com/ -g openldap -u openldap \
-F /etc/ldap/slapd.d -4
... all of the above of course different wrt. server1/server2, SID 1/2
* The I load the following LDIF files on server 1 with
$ ldapadd -YEXTERNAL -H ldapi:/// -f LDIFFILE
In sequence:
==
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: refint
=
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_bdb
==
... a bunch of schemas, like:
dn: cn=evolutionperson,cn=schema,cn=config
==
dn: olcDatabase={1}hdb,cn=config
objectClass: olcHdbConfig
objectClass: olcDatabaseConfig
olcDatabase: hdb
olcSuffix: cn=data,dc=example,dc=com
olcRootDN: cn=config
olcDbDirectory: /var/lib/ldap/cn=data,dc=example,dc=com
olcDbMode: 0660
olcDbConfig: set_cachesize 2 0 0
olcDbConfig: set_lg_bsize 2097512
olcDbConfig: set_lg_dir /var/lib/ldap/cn=data,dc=example,dc=com-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbConfig: set_lk_max_objects 5000
olcDbConfig: set_lk_max_locks 5000
olcDbConfig: set_lk_max_lockers 5000
olcDbCheckpoint: 1024 10
olcDbCachefree: 16
olcDbCachesize: 10
olcDbIDLcacheSize: 30
olcDbLinearIndex: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: ou eq
olcDbIndex: o eq
olcDbIndex: givenName eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: member eq
olcDbIndex: reader eq
olcDbIndex: writer eq
olcDbIndex: admin eq
olcAccess:
to dn.base=cn=data,dc=example,dc=com attrs=userPassword
by * auth
olcAccess:
to dn.base=cn=data,dc=example,dc=com
by dn.base=cn=data,dc=example,dc=com
Re: Two contextCSNs
Peter Mogensen wrote:
Hallvard B Furuseth wrote:
Peter Mogensen writes:
I'm trying to understand why changes made to SID 1 in my mirror set
while SID 2 is down does not get propagated to SID 2 when it comes up.
Maybe your mirror is configured with refreshAndPersist mode and you have
not specified a retry interval? Then thed default is 1 hour, according
to the slapd.conf manpage.
No. retry is 60 + (1 minute from what I read).
Since no one has complained against the 8 step procedure I posted, I
will assume that it is the correct way to load an huge LDIF into an
empty mirrormode setup.
There is no need for your step #2.
Given a valid slapcat from OpenLDAP 2.3 you should be able to slapadd it
directly in 2.4 without using -S or -w in your step #3. Therefore you don't
need step #4.
So since, it's not the procedure, it must be either my configuration or
a bug. I'll assume it's my configuration though I suspect this message
is about the same problem:
http://www.openldap.org/lists/openldap-software/200911/msg00058.html
No, that message refers to a bug that is definitely fixed in 2.4.20. (ITS#6367)
So here's my configuration in a step-by-step sequence. I do:
* First install openldap 2.4.20 / db 4.8.24 on two debian Lenny systems.
* Set /etc/ldap/slapd.conf to this:
===
gentlehup on
pidfile /var/run/slapd/slapd.pid
argsfile/var/run/slapd/slapd.args
loglevelnone
tool-threads 8
You have 8 CPUs?
# Modules
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload syncprov
# Schemas
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
# Limits
disallow bind_anon
idletimeout 120
sizelimit 2000
# TLS/Auth
TLSCACertificateFile/etc/ldap/ssl/ca.crt
TLSCertificateFile /etc/ldap/ssl/server.crt
TLSCertificateKeyFile /etc/ldap/ssl/server.nopass.key
TLSCipherSuite NULL-SHA
# Allow root to configure slapd via ldapi:///
TLSVerifyClient demand
authz-regexp
gidNumber=0\\+uidNumber=0,cn=peercred,cn=external,cn=auth
cn=config
Neatness nit: your TLSVerifyClient is obviously under the wrong comment.
authz-regexp
email=r...@example.com,cn=config,ou=dev,o=example.com,st=Denmark,c=DK
cn=config
# Mirror mode
serverID 1
database config
limits dn.exact=cn=config
time.soft=unlimited
time.hard=unlimited
size.soft=unlimited
size.hard=unlimited
The rootdn is always unlimited, this clause is superfluous.
syncrepl rid=1
provider=ldaps://server1.example.com:636/
searchbase=cn=config
type=refreshAndPersist
retry=60 +
scope=sub
schemachecking=on
bindmethod=sasl
binddn=cn=config
saslmech=EXTERNAL
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite=NULL-SHA
syncrepl rid=2
provider=ldaps://server2.example.com:636/
searchbase=cn=config
type=refreshAndPersist
retry=60 +
scope=sub
schemachecking=on
bindmethod=sasl
binddn=cn=config
saslmech=EXTERNAL
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite=NULL-SHA
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncprov-reloadhint TRUE
mirrormode on
=
* Then, I run slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d
to convert the above to a cn=config based setup.
* Then I start slapd on both servers.
$ /usr/sbin/slapd -h ldapi:/// ldaps://server1.example.com:636/ \
ldap://server1.example.com/ -g openldap -u openldap \
-F /etc/ldap/slapd.d -4
That won't work in typical Unix shells without quotes.
... all of the above of course different wrt. server1/server2, SID 1/2
* The I load the following LDIF files on server 1 with
$ ldapadd -YEXTERNAL -H ldapi:/// -fLDIFFILE
In sequence:
==
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: refint
=
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_bdb
==
Could have just used one mod request for both of those. Why are you loading
back-bdb when you're just using back-hdb and it's already loaded?
... a bunch of schemas, like:
dn: cn=evolutionperson,cn=schema,cn=config
==
dn: olcDatabase={1}hdb,cn=config
objectClass: olcHdbConfig
objectClass: olcDatabaseConfig
olcDatabase: hdb
olcSuffix: cn=data,dc=example,dc=com
olcRootDN: cn=config
olcDbDirectory: /var/lib/ldap/cn=data,dc=example,dc=com
olcDbMode: 0660
olcDbConfig: set_cachesize 2 0 0
olcDbConfig: set_lg_bsize 2097512
olcDbConfig: set_lg_dir
