Quick question: has anyone been able to get slapd to work with gssproxy on RHEL7.2?
I added this to /etc/gssproxy/gssproxy.conf:
[service/ldap] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U euid = 55 krb5_principal = ldap
I then created the ldap service principal, and added this to /etc/sysconfig/slapd:
# Tell GSSAPI to use the gssproxy interposer to broker access to # service principals. USE_GSS_PROXY=1
I then restarted slapd.
I can see in /proc/PID/maps that /usr/lib64/gssproxy/proxymech.so is loaded, and if I strace the process, it *seems* like it's using the interposer code:
32153 newfstatat(17, "gssproxy.conf", {st_mode=S_IFREG|0644, st_size=189, ...}, 0) = 0 32153 getdents(17, /* 0 entries */, 32768) = 0 32153 close(17) = 0 32153 lstat("/etc/gss/mech.d/gssproxy.conf", {st_mode=S_IFREG|0644, st_size=189, ...}) = 0 32153 open("/etc/gss/mech.d/gssproxy.conf", O_RDONLY) = 17 32153 fstat(17, {st_mode=S_IFREG|0644, st_size=189, ...}) = 0 32153 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc682964000 32153 read(17, "# GSS-API mechanism plugins\n#\n# "..., 4096) = 189 32153 read(17, "", 4096) = 0 32153 close(17) = 0 32153 munmap(0x7fc682964000, 4096) = 0 32153 stat("/usr/lib64/gssproxy/proxymech.so", {st_mode=S_IFREG|0755, st_size=104512, ...}) = 0 32153 open("/usr/lib64/gssproxy/proxymech.so", O_RDONLY|O_CLOEXEC) = 17
But if I strace gssproxy at the same time, it never receives a request. And then a little later in the slapd strace I see:
32153 open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied)
…because slapd is running as the ldap user, and can't read /etc/krb5.keytab.
The error message thrown back to a client is, as expected, permission denied:
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied)
I hopped onto #gssproxy and someone suggested:
<ab> qralston: it depends on what modules you are using in slapd configuration <ab> for example, passwd module does support kerberos but does it with direct use of Kerberos API <ab> libldap does implement GSSAPI authentication without sasl <ab> kinit module (contrib/slapd-modules/kinit) also uses direct Kerberos API
But the only additional module we're loading is back_sql.
So, to repeat: has anyone managed to get this to work? If so, how did you configure slapd?
On Thu, 2016-10-06 at 17:40 -0400, James Ralston wrote:
Quick question: has anyone been able to get slapd to work with gssproxy on RHEL7.2?
I added this to /etc/gssproxy/gssproxy.conf:
[service/ldap] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U euid = 55 krb5_principal = ldapI then created the ldap service principal, and added this to /etc/sysconfig/slapd:
# Tell GSSAPI to use the gssproxy interposer to broker access to # service principals. USE_GSS_PROXY=1I then restarted slapd.
I can see in /proc/PID/maps that /usr/lib64/gssproxy/proxymech.so is loaded, and if I strace the process, it *seems* like it's using the interposer code:
32153 newfstatat(17, "gssproxy.conf", {st_mode=S_IFREG|0644, st_size=189, ...}, 0) = 0 32153 getdents(17, /* 0 entries */, 32768) = 0 32153 close(17) = 0 32153 lstat("/etc/gss/mech.d/gssproxy.conf", {st_mode=S_IFREG|0644, st_size=189, ...}) = 0 32153 open("/etc/gss/mech.d/gssproxy.conf", O_RDONLY) = 17 32153 fstat(17, {st_mode=S_IFREG|0644, st_size=189, ...}) = 0 32153 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc682964000 32153 read(17, "# GSS-API mechanism plugins\n#\n# "..., 4096) = 189 32153 read(17, "", 4096) = 0 32153 close(17) = 0 32153 munmap(0x7fc682964000, 4096) = 0 32153 stat("/usr/lib64/gssproxy/proxymech.so", {st_mode=S_IFREG|0755, st_size=104512, ...}) = 0 32153 open("/usr/lib64/gssproxy/proxymech.so", O_RDONLY|O_CLOEXEC) = 17
But if I strace gssproxy at the same time, it never receives a request. And then a little later in the slapd strace I see:
32153 open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied)
…because slapd is running as the ldap user, and can't read /etc/krb5.keytab.
The error message thrown back to a client is, as expected, permission denied:
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied)
I hopped onto #gssproxy and someone suggested:
<ab> qralston: it depends on what modules you are using in slapd configuration <ab> for example, passwd module does support kerberos but does it with direct use of Kerberos API <ab> libldap does implement GSSAPI authentication without sasl <ab> kinit module (contrib/slapd-modules/kinit) also uses direct Kerberos API
But the only additional module we're loading is back_sql.
So, to repeat: has anyone managed to get this to work? If so, how did you configure slapd?
I have not tried, are you sure that the environment variable is being properly sourced and then passed down to children if the initialization fork/execs additional binaries ?
You can check the env in /proc/<pid>/environ of the slapd process to be sure.
Simo.
On Fri, Oct 7, 2016 at 9:58 AM, Simo Sorce simo@redhat.com wrote:
I have not tried, are you sure that the environment variable is being properly sourced and then passed down to children if the initialization fork/execs additional binaries ?
You can check the env in /proc/<pid>/environ of the slapd process to be sure.
Yes, the /proc/<pid>/environ file for the slapd process showed that it contained USE_GSS_PROXY=1 in its environment. But slapd still didn't use gssproxy.
We have a Red Hat support contract, so if this is something that should work, I can open a support request for assistance.
On 10/24/2016 11:55 AM, James Ralston wrote:
On Fri, Oct 7, 2016 at 9:58 AM, Simo Sorce simo@redhat.com wrote:
I have not tried, are you sure that the environment variable is being properly sourced and then passed down to children if the initialization fork/execs additional binaries ?
You can check the env in /proc/<pid>/environ of the slapd process to be sure.
Yes, the /proc/<pid>/environ file for the slapd process showed that it contained USE_GSS_PROXY=1 in its environment. But slapd still didn't use gssproxy.
We have a Red Hat support contract, so if this is something that should work, I can open a support request for assistance. _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org
Opening a support ticket might be an option but the first step would be to produce the logs. Can you produce the logs from GSSAPI layer and GSSproxy and share? We will try to see what is going there.
gss-proxy@lists.fedorahosted.org
-
Dmitri Pal -
James Ralston -
Simo Sorce