Is there support for the equivalent of KrbVerifyKDC off

[tparkercbn]

I have a bunch of QA and Dev servers that currently run mod_auth_kerb on CentOS 7 that I am migrating to mod_auth_gssapi on CentOS8.

With mod_auth_kerb I can set: KrbVerifyKDC off which means that I don't have to provision a keytab on all these dev/qa servers.

Is there a way to do the same with mod_auth_gssapi?

Thanks

[simo5]

Is this using the fallback to Basic Auth?

[tparkercbn]

Yes. My config for mod_auth_kerb is:
KrbMethodK5Passwd on
KrbMethodNegotiate off
KrbSaveCredentials on
KrbLocalUserMapping off
KrbVerifyKDC off

And I am trying to replicate this with mod_auth_gssapi. My users are in one realm and the server is in another and it's all bogus in dev and QA . With KrbVerifyKDC off it all works. I authenticate the user set the REMOTE_USER variable and that's enough.

[tparkercbn]

If that's the case the answer is No.
mod_auth_gssapi always verifies the credentials in order to create a ticket for the server.

Too bad. It means that mod_auth_gssapi is not a drop in upgrade from mod_auth_kerb... I'll have to find another solution.

Thanks :)

[simo5]

If you are using username/password and are not verifying the returned ticket, you might as well just use something like mod_auth_ldap or similar, there is no point in using mod_auth_gssapi if you are de-facto not using kerberos at all.

[tparkercbn]

We are using Kerberos in prod properly with keytabs and full security checking.

It's just in Dev/QA where we have been 'cheating' using mod_auth_kerb without the validity checks so that we don't have to change our config (other than set the KrbVerifyKDC off) or our server code for testing.

I'm not sure why the mod_auth_kerb guys included that flag but it has been very useful for us :)

I have created the required keytabs in QA now and everything is working as expected with mod_auth_gssapi it's just more work.

Tom

[simo5]

Just to be clar, the thing I find amusing is that you are sending username/password to the server (only way this can work w/o keytabs). That means you are not actually doing kerberos authentication (between client and server).

Sure on the server you do the equivalent of a kinit, but that's just a technical detail.

The point of kerberos is that you never let any credentials leave the client machine, using kinit (or equivalent) on the client to obtain a TGT and then grabbing a TGS to talk to the server.

I understand how mod_auth_kerb "helped" you, but that option is antithetical to the point of using kerberos in the first place, which is why mod_auth_gssapi does not offer it.

[tparkercbn]

Aren’t the username and password being sent to the server no matter what if GssapiBasicAuth on is set (with or without a keytab)? Tom From: Simo Sorce ***@***.***> Sent: June 30, 2021 6:20 AM To: gssapi/mod_auth_gssapi ***@***.***> Cc: Tom Parker ***@***.***>; Author ***@***.***> Subject: Re: [gssapi/mod_auth_gssapi] Is there support for the equivalent of KrbVerifyKDC off (#252) CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or on clicking links from unknown senders. Just to be clar, the thing I find amusing is that you are sending username/password to the server (only way this can work w/o keytabs). That means you are not actually doing kerberos authentication (between client and server). Sure on the server you do the equivalent of a kinit, but that's just a technical detail. The point of kerberos is that you never let any credentials leave the client machine, using kinit (or equivalent) on the client to obtain a TGT and then grabbing a TGS to talk to the server. I understand how mod_auth_kerb "helped" you, but that option is antithetical to the point of using kerberos in the first place, which is why mod_auth_gssapi does not offer it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#252 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABJYF5R3MFGZOCYPLZYTIMTTVMDX7ANCNFSM47QZ5SZA>.

[simo5]

Yes if you use Basic Auth, but that should be just a fallback for particular cases where an interactive client can't reach the KDC, not the default way to use it.