Kerberos after migration

Hello again.

I gave up restoring certificates as discussed in https://lists.fedorahosted.org/archives/list/[e-mail]...
While i had to recover the service and rescue data at any cost

So my decision was probably wrong but i didn't have options
I deployed RedHat instead of CentOS and then deployed fresh IPA 4.9.8

Then i migrated directory from the old cluster  excluding kerberos fields and some service accounts/groups
Rebuilt DNS etc

Initially everything was good at least users, groups and credentials were saved.
But further configuration resulted some troubles. Briefly, i can't run commands as admin and anyone else

kinit admin
Password for admin@<REALM>
[root@idm0 ~]# klist
Ticket cache: KCM:0
Default principal: admin@<REALM>

Valid starting     Expires            Service principal
06/20/22 07:42:19  06/21/22 06:42:23  krbtgt/<REALM>@<REALM>

[root@idm0 ~]# ipa user-show admin
ipa: ERROR: cannot connect to 'https://idm0...../ipa/session/json': Exceeded number of tries to forward a request.

kinit  <any other user>

ipa user-show <any other user>
ipa: ERROR: Insufficient access:  Invalid credentials

and /var/log/httpd/error.log has 
ipa: INFO: 401 Unauthorized: Insufficient access:  Invalid credential

What could be broken? This happened while i was trying to generate a keytab for kinit -kt <file> scripts...

[Rob Crittenden]

skrawczenko--- via FreeIPA-users wrote:
> Hello again.
>
> I gave up restoring certificates as discussed in https://lists.fedorahosted.org/archives/list/[e-mail]...
> While i had to recover the service and rescue data at any cost
>
> So my decision was probably wrong but i didn't have options
> I deployed RedHat instead of CentOS and then deployed fresh IPA 4.9.8
>
> Then i migrated directory from the old cluster  excluding kerberos fields and some service accounts/groups
> Rebuilt DNS etc
>
> Initially everything was good at least users, groups and credentials were saved.
> But further configuration resulted some troubles. Briefly, i can't run commands as admin and anyone else
>
> kinit admin
> Password for admin@<REALM>
> [root@idm0 ~]# klist
> Ticket cache: KCM:0
> Default principal: admin@<REALM>
>
> Valid starting     Expires            Service principal
> 06/20/22 07:42:19  06/21/22 06:42:23  krbtgt/<REALM>@<REALM>
>
> [root@idm0 ~]# ipa user-show admin
> ipa: ERROR: cannot connect to 'https://idm0...../ipa/session/json': Exceeded number of tries to forward a request.
>
> kinit  <any other user>
>
> ipa user-show <any other user>
> ipa: ERROR: Insufficient access:  Invalid credentials
>
> and /var/log/httpd/error.log has 
> ipa: INFO: 401 Unauthorized: Insufficient access:  Invalid credential
>
> What could be broken? This happened while i was trying to generate a keytab for kinit -kt <file> scripts...

You got a keytab for what? A user, service, other?

rob

[Serge Krawczenko]

keytab file for user principal
ipa-getkeytab -p user@REALM -k keytab.file

in order to initiate it like
kinit -kt keytab.file

and they perform ldapsearch -Y or ipa <some-command> from scripts for
example

and the questions are:
how could ipa-getkeytab corrupt the entire kerberos subsystem?
what is the proper way to generate this keytab

thank you

On Tue, Jun 21, 2022 at 6:51 PM Rob Crittenden  wrote:
> skrawczenko--- via FreeIPA-users wrote:
> > Hello again.
> >
> > I gave up restoring certificates as discussed in
>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> > While i had to recover the service and rescue data at any cost
> >
> > So my decision was probably wrong but i didn't have options
> > I deployed RedHat instead of CentOS and then deployed fresh IPA 4.9.8
> >
> > Then i migrated directory from the old cluster  excluding kerberos
>
> fields and some service accounts/groups
> > Rebuilt DNS etc
> >
> > Initially everything was good at least users, groups and credentials
>
> were saved.
> > But further configuration resulted some troubles. Briefly, i can't run
>
> commands as admin and anyone else
> > kinit admin
> > Password for admin@<REALM>
> > [root@idm0 ~]# klist
> > Ticket cache: KCM:0
> > Default principal: admin@<REALM>
> >
> > Valid starting     Expires            Service principal
> > 06/20/22 07:42:19  06/21/22 06:42:23  krbtgt/<REALM>@<REALM>
> >
> > [root@idm0 ~]# ipa user-show admin
> > ipa: ERROR: cannot connect to 'https://idm0...../ipa/session/json':
>
> Exceeded number of tries to forward a request.
> > kinit  <any other user>
> >
> > ipa user-show <any other user>
> > ipa: ERROR: Insufficient access:  Invalid credentials
> >
> > and /var/log/httpd/error.log has
> > ipa: INFO: 401 Unauthorized: Insufficient access:  Invalid credential
> >
> > What could be broken? This happened while i was trying to generate a
>
> keytab for kinit -kt <file> scripts...
>
> You got a keytab for what? A user, service, other?
>
> rob

[Rob Crittenden]

Serge Krawczenko via FreeIPA-users wrote:
> keytab file for user principal
> ipa-getkeytab -p user@REALM -k keytab.file
>
> in order to initiate it like
> kinit -kt keytab.file
>
> and they perform ldapsearch -Y or ipa <some-command> from scripts for
> example
>
> and the questions are:
> how could ipa-getkeytab corrupt the entire kerberos subsystem?
> what is the proper way to generate this keytab

Getting a keytab for a user changes their password.

It's hard to know what is going on with so few details. You mentioned
scripts, that this affects all users. But you only got a keytab for admin?

So I guess we need to see what you're really executing (have executed)
to figure out what is going on.

So no users at all work? How? They can't kinit? They can't use the
resulting ticket? Against which services?

rob
> thank you
>
> On Tue, Jun 21, 2022 at 6:51 PM Rob Crittenden <[e-mail]
> > wrote:
> skrawczenko--- via FreeIPA-users wrote:
> > Hello again.
> >
> > I gave up restoring certificates as discussed in
> https://lists.fedorahosted.org/archives/list/[e-mail]/thread/HAP3ZPJUPQQ7OM7H4PL7Y5WBC5E43J25/
> > While i had to recover the service and rescue data at any cost
> >
> > So my decision was probably wrong but i didn't have options
> > I deployed RedHat instead of CentOS and then deployed fresh IPA 4.9.8
> >
> > Then i migrated directory from the old cluster  excluding kerberos
> fields and some service accounts/groups
> > Rebuilt DNS etc
> >
> > Initially everything was good at least users, groups and
> credentials were saved.
> > But further configuration resulted some troubles. Briefly, i can't
> run commands as admin and anyone else
> >
> > kinit admin
> > Password for admin@<REALM>
> > [root@idm0 ~]# klist
> > Ticket cache: KCM:0
> > Default principal: admin@<REALM>
> >
> > Valid starting     Expires            Service principal
> > 06/20/22 07:42:19  06/21/22 06:42:23  krbtgt/<REALM>@<REALM>
> >
> > [root@idm0 ~]# ipa user-show admin
> > ipa: ERROR: cannot connect to
> 'https://idm0...../ipa/session/json': Exceeded number of tries to
> forward a request.
> >
> > kinit  <any other user>
> >
> > ipa user-show <any other user>
> > ipa: ERROR: Insufficient access:  Invalid credentials
> >
> >
> > and /var/log/httpd/error.log has
> > ipa: INFO: 401 Unauthorized: Insufficient access:  Invalid credential
> >
> > What could be broken? This happened while i was trying to generate
> a keytab for kinit -kt <file> scripts...
>
> You got a keytab for what? A user, service, other?
>
> rob
>
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Serge Krawczenko]

On Wed, Jun 22, 2022 at 5:43 PM Rob Crittenden  wrote:
> Serge Krawczenko via FreeIPA-users wrote:
> > keytab file for user principal
> > ipa-getkeytab -p user@REALM -k keytab.file
> >
> > in order to initiate it like
> > kinit -kt keytab.file
> >
> > and they perform ldapsearch -Y or ipa <some-command> from scripts for
> > example
> >
> > and the questions are:
> > how could ipa-getkeytab corrupt the entire kerberos subsystem?
> > what is the proper way to generate this keytab
>
> Getting a keytab for a user changes their password.
>
> It's hard to know what is going on with so few details. You mentioned
> scripts, that this affects all users. But you only got a keytab for admin?
>
> So I guess we need to see what you're really executing (have executed)
> to figure out what is going on.
>
> So no users at all work? How? They can't kinit? They can't use the
> resulting ticket? Against which services?
>
> rob

OK, let's ignore the fact i've completely broken Kerberos by trying to
generate the keytab file
Here's the more specific question and humbly awaiting your advice

I had script which was used for years to perform some tasks such as
adjusting group membership etc
It basically had following stages:

kinit -kt keytab file <user>
ldapsearch -Q -Y GSSAPI -h localhost  <whatever i want>
ipa <some commands>

This keytab file was generated for dedicated user

Obviously, kinit was required for ldap gssapi and ipa commands.

So my question is:

What's the proper way to obtain such a keytab file for my dedicated user so
script running under this user
could authenticate and be able to perform the listed operations?
Asking because I am concerned about breaking something in Kerberos again.

Here's a file used for years for this purpose on the old cluster which
hasn't survived:

klist -ket adsync.keytab
Keytab name: FILE:adsync.keytab
KVNO Timestamp         Principal
---- -----------------
--------------------------------------------------------
   4 26.10.17 07:19:37 adsync@<REALM> (aes256-cts-hmac-sha1-96)
   4 26.10.17 07:19:37 adsync@<REALM> (aes128-cts-hmac-sha1-96)
   4 26.10.17 07:19:37 adsync@<REALM> (des3-cbc-sha1)
   4 26.10.17 07:19:37 adsync@<REALM> (arcfour-hmac)

And as i mentioned in the beginning, my attempt to generate the keytab
which content actually looked
same on fresh IPA deployment had broken something and admin as well as any
users lost the ability to
authenticate.

With gratitude,

[Christian Heimes]

On 23/06/2022 13.30, Serge Krawczenko via FreeIPA-users wrote:
> kinit -kt keytab file <user>
> ldapsearch -Q -Y GSSAPI -h localhost  <whatever i want>
> ipa <some commands>
>
> This keytab file was generated for dedicated user
>
> Obviously, kinit was required for ldap gssapi and ipa commands.

Actually kinit is not needed.

Any GSSAPI-enabled client can automatically acquire or refresh a TGT by 
other means. For example if you set the environment variable 
KRB5_CLIENT_KTNAME=/path/to/keytab then ldapsearch and ipa will acquire 
TGT for the first principal in the keytab if needed.

For extra security you can use gss-proxy and let it handle the keytab 
for you. You need a mapping (e.g. map keytab to effective uid) and set 
the env var GSS_USE_PROXY=yes for the command.

Christian

[Serge Krawczenko]

On Thu, Jun 23, 2022 at 5:07 PM Christian Heimes via FreeIPA-users <
[e-mail]> wrote:
> On 23/06/2022 13.30, Serge Krawczenko via FreeIPA-users wrote:
> > kinit -kt keytab file <user>
> > ldapsearch -Q -Y GSSAPI -h localhost  <whatever i want>
> > ipa <some commands>
> >
> > This keytab file was generated for dedicated user
> >
> > Obviously, kinit was required for ldap gssapi and ipa commands.
>
> Actually kinit is not needed.
>
> Any GSSAPI-enabled client can automatically acquire or refresh a TGT by
> other means. For example if you set the environment variable
> KRB5_CLIENT_KTNAME=/path/to/keytab then ldapsearch and ipa will acquire
> TGT for the first principal in the keytab if needed.
>
> For extra security you can use gss-proxy and let it handle the keytab
> for you. You need a mapping (e.g. map keytab to effective uid) and set
> the env var GSS_USE_PROXY=yes for the command.
>
> Christian

Surprising but true.
When logged in via sssd, proper TGT seems to be activated and
ipa/ldapsearch work.
Just minor clarification:

ldapsearch operates properly with `hostname` but not localhost
With localhost i'm getting
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more
information (Server ldap/localhost@<REALM> not found in Kerberos database)
Any actions needed to enable ldap/localhost principal?

This is for better understanding rather than practical use.

Great thanks.

[Sam Morris]

On 24/06/2022 09:32, Serge Krawczenko via FreeIPA-users wrote:
> ldapsearch operates properly with `hostname` but not localhost
> With localhost i'm getting
> GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
> information (Server ldap/localhost@<REALM> not found in Kerberos database)
> Any actions needed to enable ldap/localhost principal >
> This is for better understanding rather than practical use.

ldapsearch constructs the Kerberos principal name based on 'ldap' and 
the hostname you specify. Think of it this way: ldap/server1, 
ldap/server2 are separate identities within a kerberos realm.

So, when told to connect to 'localhost' ldapsearch is very simply going 
to try to authenticate to ldap/localhost, which wouldn't exist in a 
normal Kebreros realm. As indeed, it doesn't in yours as shown by the 
error message.