0

For Kerberos Authentication together with SASL/GSSAPI Authorization on client devices I need Proxy Authorization on an OpenLDAP server running on Raspberry Pi with Debian/Raspbian Buster. I tried to follow the description in the OpenLDAP Software 2.4 Administrator's Guide about SASL Proxy Authorization but could not get it to work. Either authentication fails or the proxied user wasn't found and authorization fails. Authentication with original user works without problem:

ldap-server ~$ kinit ingo
Password for ingo@HOME.HOEFT-ONLINE.DE:
ldap-server ~$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ingo@HOME.HOEFT-ONLINE.DE
SASL SSF: 256
SASL data security layer installed.
dn:uid=ingo,ou=people,ou=home,dc=hoeft-online,dc=de

But with setting up Proxy Authorization I'm confused with the source and destination rules and where to place the attributes authzTo and authzFrom and where to enable proxyAuth.

Can someone please give a short example how to define Proxy Authorization on the LDAP server with SASL/GSSAPI Authentication?

Ingo
  • 396
  • 4
  • 11

1 Answers1

0

I wasn't able to find an example on the web about this and it took me some days to pick up the widespread details. Here is how I fit it together so others can find an example now.

For a proper Proxy Authorization with SASL/GSSAPI, that needs a Kerberos authentication, we have to specify a Kerberos principal that is used as proxy user. Then for SASL authentication on the ldap server we need the usual user mapping from the SASL auth dn to the ldap account. Now we can setup the Proxy Authorization.

Create Kerberos principal

I create anyuser to use its authentication as proxy for any user. I need it for GSSAPI authentication on client devices.

~$ kadmin -p somebody/admin addprinc -policy user anyuser

Authentication mapping

This is the usual distinguished name (dn) mapping as described in the OpenLDAP Software 2.4 Administrator's Guide about Mapping Authentication Identities.

~$ cat > /tmp/in.ldif <<EOF
dn: cn=config
changetype: modify
add: olcAuthzRegexp
olcAuthzRegexp:
  {0}uid=([^,]*),cn=gssapi,cn=auth
  uid=\$1,ou=people,ou=home,dc=hoeft-online,dc=de
-
add: olcAuthzRegexp
olcAuthzRegexp:
  {1}uid=([^,]*),cn=home.hoeft-online.de,cn=gssapi,cn=auth
  uid=\$1,ou=people,ou=home,dc=hoeft-online,dc=de
EOF

~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/in.ldif

Test the mapping with:

~$ kinit ingo
~$ ldapwhoami -Y GSSAPI -v
ldap_initialize( <DEFAULT> )
SASL/GSSAPI authentication started
SASL username: ingo@HOME.HOEFT-ONLINE.DE
SASL SSF: 256
SASL data security layer installed.
dn:uid=ingo,ou=people,ou=home,dc=hoeft-online,dc=de
Result: Success (0)

Setup SASL Proxy Authorization

Proxy Authorization is disabled by default. So first we have to enable it on the ldap server. I only want to use authzTo attributes. For possible settings look at man slapd-config for olcAuthzPolicy.

~$ cat > /tmp/in.ldif <<EOF
dn: cn=config
changetype: modify
add: olcAuthzPolicy
olcAuthzPolicy: to
EOF

~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/in.ldif
# For this modify is a restart needed
~$ sudo systemctl restart slapd.service

Now I create an anyuser posix account used as proxy. For setting the authzTo attribute look at Mapping Authentication Identities.

 ~$ cat > /tmp/in.ldif <<EOF
dn: cn=anyuser,ou=group,ou=home,dc=hoeft-online,dc=de
objectClass: top
objectClass: posixGroup
cn: anyuser
gidNumber: 1001

dn: uid=anyuser,ou=people,ou=home,dc=hoeft-online,dc=de
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: anyuser
uidNumber: 1001
gidNumber: 1001
cn: any
sn: user
loginShell: /usr/sbin/nologin
homeDirectory: /nonexistent
authzTo: dn.regex:^uid=[^,]*,ou=people,ou=home,dc=hoeft-online,dc=de$
EOF

~$ sudo slapadd -l /tmp/in.ldif

Now you can test the Proxy Authorization with:

~$ kinit -p ingo
~$ ldapwhoami -Y GSSAPI -D "uid=anyuser,ou=people,ou=home,dc=hoeft-online,dc=de"
SASL/GSSAPI authentication started
SASL username: ingo@HOME.HOEFT-ONLINE.DE
SASL SSF: 256
SASL data security layer installed.
dn:uid=ingo,ou=people,ou=home,dc=hoeft-online,dc=de

Please also note from Proxy Authorization Rules:

Source rules are extremely powerful. If ordinary users have access to write the authzTo attribute in their own entries, then they can write rules that would allow them to authorize as anyone else. As such, when using source rules, the authzTo attribute should be protected with an ACL that only allows privileged users to set its values.

Ingo
  • 396
  • 4
  • 11
  • Wouldn't be direct mapping more robust and less prone to become a security issue? – Braiam Jun 17 '20 at 15:51
  • @Braiam Sorry, I don't understand? What to map direct? Would it work against my single sign on with my kerberos and ldap? – Ingo Jun 17 '20 at 16:46
  • The next (sub?)section in the manual is called Direct Mapping, which seems to avoid the whole proxy mechanism for authentication. It prevents the "users have access to write the authzTo attribute in their own entries" problem. – Braiam Jun 17 '20 at 16:59
  • Also, yes, it would work :D – Braiam Jun 17 '20 at 17:35
  • @Braiam See example in the manual at section **15.3.1. Uses of Proxy Authorization**: "*This sort of service is useful when one entity needs to act on the behalf of many other users. For example, users may be directed to a web page to make changes to their personal information in their LDAP entry. The users authenticate to the web server to establish their identity, but the web server CGI cannot authenticate to the LDAP server as that user to make changes for them. Instead, the web server authenticates itself to the LDAP server as a service identity,..*". I need that auth against ldap server. – Ingo Jun 17 '20 at 18:24
  • I don't know why you think you do. Unless you are passing the password to LDAP so that it authenticate against kerberos (which by your examples I don't think you do), you don't have a need for proxy authentication. LDAP itself supports SASL/GSSAPI with the correct libraries by default. – Braiam Jun 17 '20 at 18:54
  • This guide may serve as example https://www.cyrusimap.org/sasl/sasl/faqs/openldap-sasl-gssapi.html – Braiam Jun 17 '20 at 18:59
  • @Braiam It's by design. Before starting my single sign on project I decided to use kerberos authentication and ldap authorization, a widely referenced solution on the web. I do not want to store and manage passwords on the ldap server. Passwords should only be managed by kerberos with its security improvements. So I authenticate against ldap with a kerberos ticket. in my first attempt I [use **nslcd** for logon](https://serverfault.com/a/993929/458473). This service can only use one user principal for authentication. – Ingo Jun 17 '20 at 19:50
  • So I have to use Proxy Authorization to give the authenticated user (kerberos ticket) access to the ldap server for authorization. But this old style service gave me [too much problems](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951536) with modern **systemd** so I decided to [use **sssd** for logon](https://serverfault.com/a/1005226/458473) instead of **nslcd**. Sssd can authenticate with a host principal from `/etc/krb5.keytab` so I do not need Proxy Authorization anymore. So everything is good ;-) – Ingo Jun 17 '20 at 19:51