[39410] in Kerberos
Re: Impersonate Kerberos user on HDFS
daemon@ATHENA.MIT.EDU (Russ Allbery)
Thu Apr 11 10:56:18 2024
From: Russ Allbery <eagle@eyrie.org>
To: Ken Hornstein via Kerberos <kerberos@mit.edu>
In-Reply-To: <202404111224.43BCOTL9014923@hedwig.cmf.nrl.navy.mil> (Ken
Hornstein via Kerberos's message of "Thu, 11 Apr 2024 08:24:29 -0400")
Date: Thu, 11 Apr 2024 07:54:39 -0700
Message-ID: <87zfu00x1s.fsf@hope.eyrie.org>
MIME-Version: 1.0
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Ken Hornstein via Kerberos <kerberos@mit.edu> writes:
> - Have access to to user's key/password and generate a ticket for that
> user using kinit. As someone else already noted, this isn't really
> impersonating a user.
> - Have access to the TGS key and generate a TGT for that user (or any user).
> This is generally referred to as "ticket printing". I don't _think_
> the Kerberos distributions come with a utility to do that, but I
> believe there are example programs floating around that do that. I
> have to say that doing so would require access to the TGS key and
> having that outside of your Kerberos database would be extremely
> dangerous as if it was compromised your entire realm would be
> compromised.
I have in the past written a variation on these two approaches as a
service that runs directly on the KDC. It accepted authenticated
requests, applied some sort of complex ACL, and, if the authenticated user
making the request passed that ACL, returned a printed ticket (and of
course logged that this was happening). Since it ran on the KDC, it
already had access to the keys required to do so. I convinced myself that
this was acceptably secure.
(The actual project was for a former employer and I don't have the source,
and there were some other weird things about that environment that meant I
was able to maintain separate keytabs for each user without worrying about
them being invalidated, so I didn't do the full ticket printing approach
based on the TGS key and just used a bunch of user keytabs since that was
a lot easier to set up without having to work too hard.)
The huge drawback of all variations on this type of approach is that you
lose the ability to distinguish between user accesses based on their own
authentication and third-party accesses via ticket printing. That can be
a real problem if anything goes wrong and you need to figure out whether
it was really the user or some ticket-printing service, and can be hard to
explain (for good reason) in various audit situations. So probably best
avoided if you can find a different approach.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
