Re: OpenLDAP 2.5 + GSSAPI + Kerberos
On 2023-07-05 11:18, dbars...@nd.edu wrote:
Total newbie here so please be gentle. I'm trying to set up a simple
ldap server that uses SASL and Kerberos for authentication. I built
OpenLDAP --with-cyrus-sasl and --enable-spasswd. I have the service
principal and testsaslauthd works. I used slapadd to build the initial
config (from slapd.ldif) and ldapadd to define a rootdn and basedn
(basically ou=people and ou=groups). Added a user (me) and a group.
You don't say what OS you are using. I am really only familiar with
Debian/Ubuntu and if I build OpenLDAP I start from the source package
and just add patches to that. This is just to explain the paths that
I use in describing my configuration.
Oh, and it might make sense for you to just use the Symas packages
if you can. Their builds are quite complete. Paths are different,
i.e. /opt/symas/openldap as a base, but most everything else just
follows.
I have a slapd.conf file at /usr/lib/sasl2 that defines keytab:
krb5.keytab, mech_list: GSSAPI, pwcheck_method: saslauthd,
saslauthd_path: /run/saslauthd/mux.
In Debian base distributions the SASL configuration for the slapd is
in /etc/ldap/sasl2/slapd.conf. My version of this file contains:
mech_list: GSSAPI plain
You do not need saslauthd to authenticate to slapd. You need that
only if you need to support simple binds to the directory and only
then on the client system.
What you do need is a ldap/ keytab. On Debian systems the
location of the keytab is set in /etc/default/slapd. This file is
a simple bash fragment and the relevant property to set is KRB5_KTNAME.
Here is a copy of my configuration:
SLAPD_CONF=/etc/ldap/slapd.d
SLAPD_USER=""
SLAPD_GROUP=""
SLAPD_SERVICES="ldap:///";
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
export KRB5_KTNAME=/etc/ldap/ldap-host.keytab
export KRB5CCNAME=/run/service-ldap.tgt
The KRB5CCNAME is there for use by replication. And, if you are on
a system with systemd you should be able to set these environment
variables there.
Running pluginviewer, I see GSSAPI. Running ldapsearch ...
supportedSASLMechanisms, it returns nothing. I've found websites that
talk about adding sasl-realm
sasl-host sasl-secprops none to slapd.conf. But this isn't
the same slapd.conf I mentioned above correct? And since I used
slapd.ldif to do the inital load, I don't have another
slapd.conf.
How to I define these variables? Also, it looks like I need a direct
mapping i.e.
authz-regexp
uid=([^,]*),cn=example.com,cn=gssapi,cn=auth
uid=$1,ou=people,dc=example,dc=com
These expressions are used to map the GSSAPI credential to an LDAP
distinguished name. Here are some edited examples from my server that
map host, ldap, service, and user principals into dn's.
olcAuthzRegexp: {0}"uid=host/(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///ou=net,dc=domain,dc=com??sub?krb5PrincipalName=host/$1...@domain.com";
olcAuthzRegexp: {1}"uid=ldap/(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///ou=net,dc=domain,dc=com??sub?krb5PrincipalName=host/$1...@domain.com";
olcAuthzRegexp: {2}"uid=service/(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///ou=auth,dc=domain,dc=com??sub?krb5PrincipalName=service/$1...@domain.com";
olcAuthzRegexp: {4}"uid=(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///dc=domain,dc=com??sub?krb5PrincipalName=$1...@domain.com";
Note, these are probably more complicated that you need since they
perform an ldap search to find the dn. The associated entries in the
directory need to have the krb5PrincipalName specified. For example:
$ ldapsearch uid=mac krb5principalname objectclass
dn: uid=mac,ou=people,dc=domain,dc=com
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: krb5Principal
krb5PrincipalName: m...@domain.com
I haven't used the more simple form in a long time, but as I remember
if the directory has a strict convention for where entries are
you could use something like:
olcAuthzRegexp: {3}"uid=(.*),cn=domain.com,cn=gssapi,cn=auth"
"uid=$1,ou=people,dc=domain,dc=com"
Note, that once you get principals mapped into dn's you will need to
set ACLs to allow access to the entries in the directory. But, you
can do that after you get the mapping working.
To get mapping working ldapwhoami is our friend. For example:
$ kinit mac
Password for m...@domain.com:
$ ldapwhoami -H ldap://ldapserver
SASL/GSSAPI authentication started
SASL username: m...@domain.com
SASL SSF: 256
SASL data security layer installed.
dn:uid=mac,ou=people,dc=domain,dc=com
If the mapping was failing I would have gotten a dn of
uid=mac,cn=domain.com,cn=gssapi,cn=auth.
Where and how does that get defined? Any and all help would be greatly
appreciated!
This gets defined in the cn=config branch of the directory. Because
I started using OpenLDAP before cn=config existed I still use files
base configuration, sort of. I dump the cn=config branch of the
directory, edit the ldif, and then reload it with sl
Re: -Y external and SUSE
Hi Stefan,
can you please post the output from
rpm -qf $(which ldapsearch)
best regards
Michael
Am Mittwoch, dem 05.07.2023 um 20:37 +0200 schrieb Stefan Kania:
> Hi to all,
>
> I just installed openSUSE 15.5 and the actual symas packages. After
> installing OpenLDAP I could start slapd but "ldapsearch -Y external -
> H
> ldapi:///" is giving me a "can't connect to ldapserver"
>
> I found out that the ldap-socket on SUSE is (the same a on Debian
> systems) in /var/symas/run/ldapi and I can see:
>
> ss -lp | grep slapd
> u_str LISTEN 0 2048 /var/symas/run/ldapi
> 15214 * 0 users:(("slapd",pid=1431,fd=9))
>
> but doing a ldapsearch:
> provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5
> ldap_url_parse_ext(ldapi:///)
> ldap_create
> ldap_url_parse_ext(ldapi:///??base)
> ldap_sasl_interactive_bind: user selected: EXTERNAL
> ldap_int_sasl_bind: EXTERNAL
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_path
> ldap_new_socket: 3
> ldap_connect_to_path: Trying /run/slapd/ldapi
> ldap_connect_timeout: fd: 3 tm: -1 async: 0
> ldap_ndelay_on: 3
> ldap_close_socket: 3
> ldap_msgfree
> ldap_err2string
> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
>
> You can see, that ldapsearch is looking in /run/slapd/ for the
> socket.
> How can I change this?
>
> I tested with setting a link:
> ln -s /var/symas/run/ldapi /run/slapd/
>
> and ldapseach wit "external" is working. But this was only a test.
> After
> rebooting the system the link is gone.
>
>
> So how can I either change the behavior of the ldap-commands or
> changing
> the path where the socket will be stored?
>
> Thank's for any help
signature.asc
Description: This is a digitally signed message part
OpenLDAP 2.5 + GSSAPI + Kerberos
Total newbie here so please be gentle. I'm trying to set up a simple ldap server that uses SASL and Kerberos for authentication. I built OpenLDAP --with-cyrus-sasl and --enable-spasswd. I have the service principal and testsaslauthd works. I used slapadd to build the initial config (from slapd.ldif) and ldapadd to define a rootdn and basedn (basically ou=people and ou=groups). Added a user (me) and a group. I have a slapd.conf file at /usr/lib/sasl2 that defines keytab: krb5.keytab, mech_list: GSSAPI, pwcheck_method: saslauthd, saslauthd_path: /run/saslauthd/mux. Running pluginviewer, I see GSSAPI. Running ldapsearch ... supportedSASLMechanisms, it returns nothing. I've found websites that talk about adding sasl-realm sasl-host sasl-secprops none to slapd.conf. But this isn't the same slapd.conf I mentioned above correct? And since I used slapd.ldif to do the inital load, I don't have another slapd.conf. How to I define these variables? Also, it looks like I need a direct mapping i.e. authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=com Where and how does that get defined? Any and all help would be greatly appreciated!
Re: -Y external and SUSE
Are you using the (suse) system ldapsearch, or ldapsearch that came with
symas openldap?
I have been bitten by that one. Try the other one, if you also have two.
Op 05-07-2023 om 20:37 schreef Stefan Kania:
Hi to all,
I just installed openSUSE 15.5 and the actual symas packages. After
installing OpenLDAP I could start slapd but "ldapsearch -Y external -H
ldapi:///" is giving me a "can't connect to ldapserver"
I found out that the ldap-socket on SUSE is (the same a on Debian
systems) in /var/symas/run/ldapi and I can see:
ss -lp | grep slapd
u_str LISTEN 0 2048 /var/symas/run/ldapi
15214 * 0 users:(("slapd",pid=1431,fd=9))
but doing a ldapsearch:
provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5
ldap_url_parse_ext(ldapi:///)
ldap_create
ldap_url_parse_ext(ldapi:///??base)
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_path
ldap_new_socket: 3
ldap_connect_to_path: Trying /run/slapd/ldapi
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_close_socket: 3
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
You can see, that ldapsearch is looking in /run/slapd/ for the socket.
How can I change this?
I tested with setting a link:
ln -s /var/symas/run/ldapi /run/slapd/
and ldapseach wit "external" is working. But this was only a test. After
rebooting the system the link is gone.
So how can I either change the behavior of the ldap-commands or changing
the path where the socket will be stored?
Thank's for any help
Re: -Y external and SUSE
Have you tried ldap.conf or ldaprc "URI" setting?
On 6/07/2023 4:37 am, Stefan Kania wrote:
Hi to all,
I just installed openSUSE 15.5 and the actual symas packages. After
installing OpenLDAP I could start slapd but "ldapsearch -Y external -H
ldapi:///" is giving me a "can't connect to ldapserver"
I found out that the ldap-socket on SUSE is (the same a on Debian
systems) in /var/symas/run/ldapi and I can see:
ss -lp | grep slapd
u_str LISTEN 0 2048 /var/symas/run/ldapi
15214 * 0 users:(("slapd",pid=1431,fd=9))
but doing a ldapsearch:
provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5
ldap_url_parse_ext(ldapi:///)
ldap_create
ldap_url_parse_ext(ldapi:///??base)
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_path
ldap_new_socket: 3
ldap_connect_to_path: Trying /run/slapd/ldapi
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_close_socket: 3
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
You can see, that ldapsearch is looking in /run/slapd/ for the socket.
How can I change this?
I tested with setting a link:
ln -s /var/symas/run/ldapi /run/slapd/
and ldapseach wit "external" is working. But this was only a test.
After rebooting the system the link is gone.
So how can I either change the behavior of the ldap-commands or
changing the path where the socket will be stored?
Thank's for any help
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
-Y external and SUSE
Hi to all,
I just installed openSUSE 15.5 and the actual symas packages. After
installing OpenLDAP I could start slapd but "ldapsearch -Y external -H
ldapi:///" is giving me a "can't connect to ldapserver"
I found out that the ldap-socket on SUSE is (the same a on Debian
systems) in /var/symas/run/ldapi and I can see:
ss -lp | grep slapd
u_str LISTEN 0 2048 /var/symas/run/ldapi
15214 * 0users:(("slapd",pid=1431,fd=9))
but doing a ldapsearch:
provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5
ldap_url_parse_ext(ldapi:///)
ldap_create
ldap_url_parse_ext(ldapi:///??base)
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_path
ldap_new_socket: 3
ldap_connect_to_path: Trying /run/slapd/ldapi
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_close_socket: 3
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
You can see, that ldapsearch is looking in /run/slapd/ for the socket.
How can I change this?
I tested with setting a link:
ln -s /var/symas/run/ldapi /run/slapd/
and ldapseach wit "external" is working. But this was only a test. After
rebooting the system the link is gone.
So how can I either change the behavior of the ldap-commands or changing
the path where the socket will be stored?
Thank's for any help
smime.p7s
Description: S/MIME Cryptographic Signature
Re: mdb_env_close, mdb_dbi_close, mdb_dbi_open
I'll rephrase. For mdb_env_close: "Only a single thread may call this function". Is the meaning same as "For each environment, this function can be called at most once (from any thread)."? For mdb_dbi_close: "This call is not mutex protected. Handles should only be closed by a single thread". Is the meaning same as "For each handle, this function can be called at most once (from any thread). If you want to close different handles on the same environment from different threads, you need to synchronize their use."? If someone can confirm my understanding (or correct if wrong), I'd appreciate it. Jul 2, 2023, 09:46 by samd...@tuta.io: > Thanks, knowing that (complete independence of environments) makes things > easier. > > Some follow-ups for clarification, > > * Why did "Only a single thread may call this function" have to be mentioned > at all for mdb_env_close? It can afaik only be called at most once per > environment anyway. (It seems implied by "The environment handle will be > freed and must not be used again after this call", and sort of too from the > caveats about opening an environment on disk only once). > > * About mdb_dbi_close, to "Handles should only be closed by a single thread", > would it be worth it to add something like "or mdb_dbi_close should be > synchronized, if called from multiple threads" ? > > - Sam > > Jul 1, 2023, 17:32 by h...@symas.com: > >> Sam Dave wrote: >> >>> Hi, >>> >>> I'm interested in understanding these functions better. These are not >>> criticisms.. since these functions are called rarely, I have no problem >>> synchronizing >>> them. I ask only for curiosity's sake. >>> >> >> Everything in LMDB is defined within the context of a single environment. >> That should already be clear from the documentation. >> >> The constraints you reference below only apply within a single environment. >> Separate environments are completely independent of each other. >> >>> >>> * mdb_env_close: "Only a single thread may call this function." Why can't >>> different environments (separate files/dirs on disk) be closed from >>> different threads? >>> >>> * mdb_dbi_close: "Handles should only be closed by a single thread." Why >>> can't at least databases on different environments (separate files/dirs on >>> disk) be >>> closed from different threads? >>> >>> * mdb_dbi_open: "This function must not be called from multiple concurrent >>> transactions in the same process." Why can't this function be called from >>> different >>> threads to open at least databases on different environments (separate >>> files/dirs on disk)? >>> >>> What are the reasons for these limitations, under the hood? Could these >>> functions have been designed in a different way, to allow for more >>> multithreading >>> (again, I'm not asking for this, I'm just curious). >>> >>> - Sam >>> >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > >
Re: trying to understand SID portion in contextCSN
--On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb wrote: serverID 222 ldaps://ldapm01.company.com serverID 221 ldaps://ldapm02.company.com serverID 212 ldaps://ldapm03.company.com serverID 211 ldaps://ldapm04.company.com And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get: [root@ldapm04 ~]# slapcat | grep contextcsn -i contextCSN: 20180917142109.765066Z#00#000#00 contextCSN: 20230622151102.137085Z#00#001#00 contextCSN: 20230622151105.174343Z#00#002#00 contextCSN: 20230627112536.529432Z#00#0dd#00 contextCSN: 20230627112536.529512Z#00#0de#00 The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this: Yet: all info I can find tells me that the third field of contextCSN is "the SID". Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..? Hi! So #000# is as you noted an old SID from when the system used single provider. The SID values are indeed in hex. Your current non-zero SIDS indicate: You have servers with SID values 001, 002 that last received a direct write operation on 2023/06/22, about 3 seconds apart. You have servers with SID values 221 (0dd) and 222 (0de) that last received a direct write operation on 2023/06/27, during the same second. Any server that has a different SID value that has never received a direct write operation will not appear in the list. Regards, Quanah
trying to understand SID portion in contextCSN
Hi! Trying to better understand the contextCSN attribute. ContextCSN is formatted like: TIMESTAMP#COUNT#SID#MOD My question is on the SID part: ServerID. I have the following serverID configuration in our 4-server Multi-Master PoC setup: serverID 222 ldaps://ldapm01.company.com serverID 221 ldaps://ldapm02.company.com serverID 212 ldaps://ldapm03.company.com serverID 211 ldaps://ldapm04.company.com And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get: [root@ldapm04 ~]# slapcat | grep contextcsn -i contextCSN: 20180917142109.765066Z#00#000#00 contextCSN: 20230622151102.137085Z#00#001#00 contextCSN: 20230622151105.174343Z#00#002#00 contextCSN: 20230627112536.529432Z#00#0dd#00 contextCSN: 20230627112536.529512Z#00#0de#00 The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this: syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand Now the actual question: contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above. Yet: all info I can find tells me that the third field of contextCSN is "the SID". Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..? Curious :-) Thanks!
