0

as an admin, I've been trying to make 2 different RootDN accounts login with a single kerberos account lately.

I have two different rootDN and password

-D "cn=admin,cn=config" 
-D "cn=admin,dc=example,dc=com"

when I login via Kerberos like;

kinit ldap/admin

I want to use both with "ldap/admin" principal;

-D "cn=admin,cn=config" -W -Y GSSAPI
-D "cn=admin,dc=example,dc=com" -W -Y GSSAPI

I have applied the relevant commands to achieve this, but I can only access one ROOTDN, but I want to operate on both. How can I do this without olcAccess?

olcAuthzRegexp: {0}"uid=ldap/admin,cn=example.com,cn=gssapi,cn=auth" "cn=admin,dc=example,dc=com'
olcAuthzRegexp: {1}"uid=ldap/admin,cn=example.com,cn=gssapi,cn=auth" "cn=admin,cn=config'

I try access two Different RootDN with Single Principal

Wiktor Stribiżew
  • 607,720
  • 39
  • 448
  • 563
Ichigo Kurosaki
  • 135
  • 1
  • 6

1 Answers1

0

The -D and -W options only apply to simple binds. For SASL bind, you need to use -X to specify the SASL "authorization identity":

$ ldapwhoami -Y GSSAPI -X "dn:cn=admin,cn=config"

However, olcAuthzRegexp only defines the default authzid (i.e. the regexps are used for authnid transformation to authzid) and is not what you want for -X.

In order to be allowed to specify custom identities, I believe you need to use olcAuthzPolicy in combination with either authzTo on your own authnid entry, or authzFrom on the entry that you intend to impersonate. (Yes, the rootDN can have an actual entry.)

For example, with olcAuthzPolicy: any, the entry would need to have:

dn: cn=admin,dc=example,dc=com
authzFrom: {0}dn.exact="uid=ldap/admin,cn=example.com,cn=gssapi,cn=auth"

If you are not able to create a real entry at cn=admin,cn=config (the config backend will most likely not support this), you will need to use the opposite approach with authzTo instead:

  1. Define olcAuthzRegexp to map your "cn=gssapi,cn=auth" DN to one real DN that exists in the main database backend:

    olcAuthzRegexp: {0}"uid=ldap/admin,cn=example.com,cn=gssapi,cn=auth" "cn=admin,dc=example,dc=com"

    Verify that your connections are authorized as this DN by default:

    $ ldapwhoami -Y GSSAPI
dn:cn=admin,dc=example,dc=com

  2. Actually create the DN, with its authzTo attributes listing the DNs that it is allowed to impersonate (authorize as):

    dn: cn=admin,dc=example,dc=com
authzTo: {0}dn.exact="cn=admin,cn=config"

  3. Set olcAuthzPolicy to both or from, then use the -X option to specify the DN that you want to assume:

    $ ldapwhoami -Y GSSAPI -X "dn:cn=admin,cn=config"
dn:cn=admin,cn=config

Make sure users are not allowed to edit authzTo on their own entries, or any other entry. Use olcAccess to prevent this.

user1686
  • 13,155
  • 2
  • 35
  • 54
  • Not it is not working like that; output is SASL/GSSAPI authentication started ldap_sasl_interactive_bind: Insufficient access (50) additional info: SASL(-14): authorization failure: not authorized – Ichigo Kurosaki Apr 28 '23 at 07:42
  • Yes, see the edit I just added regarding that. – user1686 Apr 28 '23 at 07:44
  • I applied; << authzTo: dn.regex:^cn=admin,cn=config$ >> on << dn: cn=admin,dc=example,dc=com >> but same error, – Ichigo Kurosaki Apr 28 '23 at 07:48
  • What DN do you get from a plain `ldapwhoami -Y GSSAPI` without any authz options? – user1686 Apr 28 '23 at 07:50
  • SASL/GSSAPI authentication started SASL username: ldap/admin@EXAMPLE.COM SASL SSF: 256 SASL data security layer installed. dn:cn=admin,cn=config
     – Ichigo Kurosaki Apr 28 '23 at 07:51
  • Okay, so you first need to remove the second olcAuthzRegexp (the {1} cn=config one), because you have set authzTo on the `cn=admin,dc=example,dc=com` entry, so you need to have that as your "default" identity. (You may need to restart slapd after removing authzRegexp rules...) – user1686 Apr 28 '23 at 07:53
  • (Also, I remember Stack Overflow developers saying that advanced Markdown formatting _deliberately_ does not work in comments (only single-backtick inline markup does); they want to encourage people to edit things into their main post instead.) – user1686 Apr 28 '23 at 07:56
  • Thank you very much for your help master!!! I was able to reach my goal. @user1686 – Ichigo Kurosaki Apr 28 '23 at 08:09
  • by the way, ı want to ask, can u give any example about olcAccess rule to disable "authzTo" and "authzTo" , for example only "cn=admin,dc=example,dc=com" user can use "authzTo/authzTo" attributes and denied all other users? – Ichigo Kurosaki Apr 28 '23 at 12:54
  • Something along the lines of `to attrs="authzFrom,authzTo" by * auth`. (The rule needs to grant `by * auth` at least; you can't use `by * none`.) You don't need to explicitly grant access to the rootDN, as it always has full access due to being the rootDN, so this is an example of granting access to group members instead: `to attrs="authzFrom,authzTo" by group="cn=Admins,o=Example" manage by * auth`. – user1686 Apr 28 '23 at 13:01