Integrating Kerberos and privacyidea

With Privacyidea 2.8 we have the possibility to use REMOTE_USER for
authentication. mod_auth_kerb can set that when using kerberos, so I
tried that:

    <Directory />
      # For Apache 2.4 you need to set this:5D
      #Require all granted
      Options FollowSymLinks
      AllowOverride None
      SSLRequireSSL
      AuthType Kerberos
      AuthName "Kerberos Login"
      KrbMethodNegotiate On
      KrbMethodK5Passwd On
      KrbAuthRealms JOCHEN.ORG
      Krb5KeyTab /etc/apache2/http.keytab
      KrbServiceName HTTP
      KrbSaveCredentials On
      require valid-user
    </Directory>

I have a webui policy that allows remote_user. Privacyidea now
recognizes that REMOTE_USER is set and offers to log in as
"jochen@JOCHEN.ORG".

If I do that, privacyidea still tries to authenticate against my LDAP
resolver and answers: Authentication failed. Wrong Credentials.

Any idea why my REMOTE_USER does not work? I tried converting the
uppercase Kerberos realm to lowercase, which is used in privacyidea,
but that to didn’t work.

Anything that must be done to authenticate against Kerberos?

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

With Privacyidea 2.8 we have the possibility to use REMOTE_USER for
authentication. mod_auth_kerb can set that when using kerberos, so I
tried that:

    <Directory />
      # For Apache 2.4 you need to set this:5D
      #Require all granted
      Options FollowSymLinks
      AllowOverride None
      SSLRequireSSL
      AuthType Kerberos
      AuthName "Kerberos Login"
      KrbMethodNegotiate On
      KrbMethodK5Passwd On
      KrbAuthRealms JOCHEN.ORG
      Krb5KeyTab /etc/apache2/http.keytab
      KrbServiceName HTTP
      KrbSaveCredentials On
      require valid-user
    </Directory>

I have a webui policy that allows remote_user. Privacyidea now
recognizes that REMOTE_USER is set and offers to log in as
jochen@JOCHEN.ORG”.

If I do that, privacyidea still tries to authenticate against my LDAP
resolver and answers: Authentication failed. Wrong Credentials.

Hi Jochen,

how do you know, that it’s trying to authenticate against privacyIDEA?
Can you provide some debug log?

The point is, that jochen@JOCHEN.ORG needs to be identified as a user in
privacyIDEA. If you have the atSignSpitting (default) you need to have a
realm “JOCHEN.ORG”, which contains the user “jochen”.

Otherwise the checking for the user object will fail.

Kind regards
CorneliusAm Montag, den 30.11.2015, 22:09 +0100 schrieb Jochen Hein:

Any idea why my REMOTE_USER does not work? I tried converting the
uppercase Kerberos realm to lowercase, which is used in privacyidea,
but that to didn’t work.

Anything that must be done to authenticate against Kerberos?

Jochen


The only problem with troubleshooting is that the trouble shoots back.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

Hi Jochen,

ok, we might have a lower/upper case problem here.
privacyIDEA will lowercase the realm names, so are case insensitive as
far as realms is concerned.

I will wait for you logs.
But I guess that the user jochen@JOCHEN.ORG will split to the user
“jochen” in realm “JOCHEN.ORG”, which will not match the realm.

I attached a hotfix of file privacyidea/lib/user.py.
If you want to, you may replace this file, restart the service and try
again.

Kind regards
CorneliusAm Dienstag, den 01.12.2015, 07:36 +0100 schrieb Hein, Jochen:

Hi Cornelius,

Am 2015-11-30 23:01, schrieb Cornelius Kölbel:

Am Montag, den 30.11.2015, 22:09 +0100 schrieb Jochen Hein:

With Privacyidea 2.8 we have the possibility to use REMOTE_USER for
authentication. mod_auth_kerb can set that when using kerberos, so I
tried that:

how do you know, that it’s trying to authenticate against privacyIDEA?
Can you provide some debug log?

I saw failed accesses to the LDAP server (my userstore). I’m not @home
so I can’t access the logs right now.

The point is, that jochen@JOCHEN.ORG needs to be identified as a user
in
privacyIDEA. If you have the atSignSpitting (default) you need to have
a
realm “JOCHEN.ORG”, which contains the user “jochen”.

My privacyidea realm is jochen.org (lower case), so that doesn’t work.
I can’t create a second realm JOCHEN.ORG - that changed my original and
default realm
and I still had only one realm jochen.org.

I guess I’ll create a throwaway instance of privacyidea to do further
tests, but
that will take some time.

Otherwise the checking for the user object will fail.
https://github.com/privacyidea/privacyidea/blob/master/privacyidea/api/auth.py#L208

Yes, that’s most probably what I see.

Jochen


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

user.py (23.5 KB)

signature.asc (836 Bytes)

Hi Jochen,

thought so.
I will run the other tests and commit it.

The blank is on purpose.

The reason is, that you can have a user jochen@jochen.org in the realm
@realm2.com”!

If we would print “jochen@jochen.org” we would not know, if it is the
user “jochen@jochen.org” in the default realm or the user jochen in the
realm @jochen.org.

There might be other ways. In the beginning there was also the word
“realm”, but thats to much, to big a button etc. etc.

Kind regards
CorneliusAm Dienstag, den 01.12.2015, 17:53 +0100 schrieb Jochen Hein:

Hi Cornelius,

Cornelius Kölbel <@cornelinux> writes:

I attached a hotfix of file privacyidea/lib/user.py.
If you want to, you may replace this file, restart the service and try
again.

Thanks for the fix - it works for me as expected. I tried a similar
change in webui/login.py - which did not work… Do you still need some
logs?

I noticed that in the top right corner the logged in user is displayed
as “jochen@JOCHEN.ORG (user)” - that’s also the case with a
normal login. I expected no blank between user and realm - is that
intentional?

Jochen


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

Hi Cornelius,

With Privacyidea 2.8 we have the possibility to use REMOTE_USER for
authentication. mod_auth_kerb can set that when using kerberos, so I
tried that:

how do you know, that it’s trying to authenticate against privacyIDEA?
Can you provide some debug log?

I saw failed accesses to the LDAP server (my userstore). I’m not @home
so I can’t access the logs right now.

The point is, that jochen@JOCHEN.ORG needs to be identified as a user
in
privacyIDEA. If you have the atSignSpitting (default) you need to have
a
realm “JOCHEN.ORG”, which contains the user “jochen”.

My privacyidea realm is jochen.org (lower case), so that doesn’t work.
I can’t create a second realm JOCHEN.ORG - that changed my original and
default realm
and I still had only one realm jochen.org.

I guess I’ll create a throwaway instance of privacyidea to do further
tests, but
that will take some time.

Otherwise the checking for the user object will fail.
https://github.com/privacyidea/privacyidea/blob/master/privacyidea/api/auth.py#L208

Yes, that’s most probably what I see.

JochenAm 2015-11-30 23:01, schrieb Cornelius Kölbel:

Am Montag, den 30.11.2015, 22:09 +0100 schrieb Jochen Hein:

Hi Cornelius,

Cornelius Kölbel cornelius.koelbel@netknights.it writes:

I attached a hotfix of file privacyidea/lib/user.py.
If you want to, you may replace this file, restart the service and try
again.

Thanks for the fix - it works for me as expected. I tried a similar
change in webui/login.py - which did not work… Do you still need some
logs?

I noticed that in the top right corner the logged in user is displayed
as “jochen@JOCHEN.ORG (user)” - that’s also the case with a
normal login. I expected no blank between user and realm - is that
intentional?

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

Jochen Hein <@Jochen_Hein> writes:

[That still works for me, but I’d like to add some experiences.]

With Privacyidea 2.8 we have the possibility to use REMOTE_USER for
authentication. mod_auth_kerb can set that when using kerberos, so I
tried that:

    <Directory />
      # For Apache 2.4 you need to set this:5D
      #Require all granted
      Options FollowSymLinks
      AllowOverride None
      SSLRequireSSL
      AuthType Kerberos
      AuthName "Kerberos Login"
      KrbMethodNegotiate On
      KrbMethodK5Passwd On
      KrbAuthRealms JOCHEN.ORG
      Krb5KeyTab /etc/apache2/http.keytab
      KrbServiceName HTTP
      KrbSaveCredentials On
      require valid-user
        ^^^^^^^^^^^^^^^^^^

That’s ok for the WebUI, but my OpenVPN access via RADIUS stopped
working. I saw this in the “freeradius -X” output:

rlm_perl: privacyIDEA request failed: 401 Unauthorized
rlm_perl: Can not parse response from privacyIDEA.

and after adding DEBUG = true in /etc/privacyidea/rlm_perl.ini
and some tries:

rlm_perl: Content 401 Unauthorized

Unauthorized

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required.


Apache/2.4.7 (Ubuntu) Server at athene.jochen.org Port 443
rlm_perl: privacyIDEA request failed: 401 Unauthorized
rlm_perl: Can not parse response from privacyIDEA.

rlm_perl: Content 403 Forbidden

Forbidden

You don’t have permission to access /validate/check on this server.


Apache/2.4.7 (Ubuntu) Server at athene.jochen.org Port 443
rlm_perl: privacyIDEA request failed: 403 Forbidden
rlm_perl: Can not parse response from privacyIDEA.

That got me on the right track - I needed to add the following to the
apache configuration:

    <Location /validate/check>
            Require all granted
            Options FollowSymLinks
            AllowOverride None
    </Location>

Are there other s that should be added?

I’ve also added:

    <Location /ttype/yubikey>
            Require all granted
            Options FollowSymLinks
            AllowOverride None
    </Location>

I failed to use the Yubikey endpoint in Kolab-Winterfell - I didn’t try
this yet, but it seems to be a reasonable guess. I’ll get back after
some tests…

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

For “normal” authentications like the one used by the RADIUS plugin you
need to have the API endpoint /validate/check available.
So there should be no basic auth on this endpoint - just as you assumed.

If you want to use U2F this is handled via /ttype/u2f.

Each token type can implement a function that is called when calling the
endpoint /ttype/

Kind regards
CorneliusAm Montag, 29. Februar 2016 19:36:06 UTC+1 schrieb Jochen Hein:

Jochen Hein jochen@jochen.org writes:

[That still works for me, but I’d like to add some experiences.]

With Privacyidea 2.8 we have the possibility to use REMOTE_USER for
authentication. mod_auth_kerb can set that when using kerberos, so I
tried that:

    <Directory /> 
      # For Apache 2.4 you need to set this:5D 
      #Require all granted 
      Options FollowSymLinks 
      AllowOverride None 
      SSLRequireSSL 
      AuthType Kerberos 
      AuthName "Kerberos Login" 
      KrbMethodNegotiate On 
      KrbMethodK5Passwd On 
      KrbAuthRealms JOCHEN.ORG 
      Krb5KeyTab /etc/apache2/http.keytab 
      KrbServiceName HTTP 
      KrbSaveCredentials On 
      require valid-user 
        ^^^^^^^^^^^^^^^^^^ 

That’s ok for the WebUI, but my OpenVPN access via RADIUS stopped
working. I saw this in the “freeradius -X” output:

rlm_perl: privacyIDEA request failed: 401 Unauthorized
rlm_perl: Can not parse response from privacyIDEA.

and after adding DEBUG = true in /etc/privacyidea/rlm_perl.ini
and some tries:

rlm_perl: Content

401 Unauthorized

Unauthorized

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.


Apache/2.4.7 (Ubuntu) Server at athene.jochen.org Port 443 rlm_perl: privacyIDEA request failed: 401 Unauthorized rlm_perl: Can not parse response from privacyIDEA.

rlm_perl: Content

403 Forbidden

Forbidden

You don't have permission to access /validate/check on this server.


Apache/2.4.7 (Ubuntu) Server at athene.jochen.org Port 443 rlm_perl: privacyIDEA request failed: 403 Forbidden rlm_perl: Can not parse response from privacyIDEA.

That got me on the right track - I needed to add the following to the
apache configuration:

    <Location /validate/check> 
            Require all granted 
            Options FollowSymLinks 
            AllowOverride None 
    </Location> 

Are there other s that should be added?

I’ve also added:

    <Location /ttype/yubikey> 
            Require all granted 
            Options FollowSymLinks 
            AllowOverride None 
    </Location> 

I failed to use the Yubikey endpoint in Kolab-Winterfell - I didn’t try
this yet, but it seems to be a reasonable guess. I’ll get back after
some tests…

Jochen

The only problem with troubleshooting is that the trouble shoots back.

Cornelius Kölbel cornelius.koelbel@netknights.it writes:

For “normal” authentications like the one used by the RADIUS plugin you
need to have the API endpoint /validate/check available.
So there should be no basic auth on this endpoint - just as you assumed.

If you want to use U2F this is handled via /ttype/u2f.

Each token type can implement a function that is called when calling the
endpoint /ttype/

Thanks for the confirmation. I’ve added some comments to the
documentation:

Any comments?

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

Hi Jochen,

I know others are using this functionality with mod_auth_mellon to do
SAML.

So maybe one day we might create a new sub page with several examples
like:

  • kerberos
  • mellon / SAML
  • LDAP

But I think it is ok to leave it there for now.

Thanks a lot
CorneliusAm Donnerstag, den 03.03.2016, 16:33 +0100 schrieb Jochen Hein:

Cornelius Kölbel <@cornelinux> writes:

For “normal” authentications like the one used by the RADIUS plugin you
need to have the API endpoint /validate/check available.
So there should be no basic auth on this endpoint - just as you assumed.

If you want to use U2F this is handled via /ttype/u2f.

Each token type can implement a function that is called when calling the
endpoint /ttype/

Thanks for the confirmation. I’ve added some comments to the
documentation:
Add documentation for kerberos auth in webui by jh23453 · Pull Request #334 · privacyidea/privacyidea · GitHub

Any comments?

Jochen


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

Cornelius Kölbel cornelius.koelbel@netknights.it writes:

I know others are using this functionality with mod_auth_mellon to do
SAML.

First time I hear about that module. I’m not sure if I find it useful
for my systems, but I’ll have a look and think about it.

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

Jochen Hein <@Jochen_Hein> writes:

Jochen Hein <@Jochen_Hein> writes:

[That still works for me, but I’d like to add some experiences.]

There are some things not quite working…

I’ve enrolled a yubikey to use it in AES mode, because Kolab can access
Yubicos servers for OTP, but not privacyidea. So I wanted to try
privacyideas yubikey endpoint. That’s a story for another mail…

So I used “privacyidea yubikey_mass_enroll” and got 401 responses for
/token and /auth. Using

    <Location /token>
            Require all granted
            Options FollowSymLinks
            AllowOverride None
    </Location>

worked for enrollment, but not for webui access. This is something what
I need to check further - just as a reminder that SSO has still some
kinks for me.

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

Cornelius Kölbel cornelius.koelbel@netknights.it writes:

The /token endpoint needs an authenticated user!

For now I’ve disabled Kerberos while I’m working on pam_yubico. Thanks
for the hint, I’ll keep that in mind.

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

The /token endpoint needs an authenticated user!Am Sonntag, 6. März 2016 13:51:00 UTC+1 schrieb Jochen Hein:

Jochen Hein jochen@jochen.org writes:

Jochen Hein jochen@jochen.org writes:

[That still works for me, but I’d like to add some experiences.]

There are some things not quite working…

I’ve enrolled a yubikey to use it in AES mode, because Kolab can access
Yubicos servers for OTP, but not privacyidea. So I wanted to try
privacyideas yubikey endpoint. That’s a story for another mail…

So I used “privacyidea yubikey_mass_enroll” and got 401 responses for
/token and /auth. Using

    <Location /token> 
            Require all granted 
            Options FollowSymLinks 
            AllowOverride None 
    </Location> 

worked for enrollment, but not for webui access. This is something what
I need to check further - just as a reminder that SSO has still some
kinks for me.

Jochen


The only problem with troubleshooting is that the trouble shoots back.