Copy:
[email protected] (
[email protected])
Since it will take years for all of our systems to get the new kerberos, we're going to add duo explicitly. We use ansible, so we can update the pam configuration of all our systems pretty easily. We'll just add a pam call to our own code after the
normal authentication. To avoid having to set up every system to talk to DUO, we'll have a simple service (probably running on the KDCs) that does it.
The script that calls this can decide whether or not to use DUO, which would be harder for KDC, since it doesn't have the data. E.g. We may not use DUO for connections that come from within our department, and we certainly won't use them if the user has
already done an OTP authentication. (Staff will use that rather than DUO, so avoid having systems work depend upon an Internet service.)
One surprise in doing all of this is that there seems to be no standard utility to let us see the auth indicator for the user's credentials. I'm probably doing to use one of the test programs (adata). It seems to be complicated by having the auth
indicator in the encrypted part of the ticket.
To be honest, after looking at the details, I'm not sure how useful doing DUO in the KDC would be. We don't want the user to have to do DUO for screen locks, and there are a number of other situations like that. The RADIUS callout is still useful, e.g.
for using a University LDAP server for passwords so we don't have to give most users a separate password.
________________________________
From: Ken Hornstein <
[email protected]>
Sent: Wednesday, July 31, 2024 3:44 PM
To: Charles Hedrick <
[email protected]>
Cc:
[email protected] <
[email protected]>
Subject: Re: one time password integration
We're looking at one time password integration (DUO). A while ago
changes were made to allow a longer timeout, since users may take a
while to respond to DUO requests. Since this isn't in a release yet, and
it takes years for new versions to show up on all of our systems, we
can't depend upon the changes now. But I'd like it to work in the long
run.
There's another issue beyond the timeout, and it's not clear to me that
the change takes it into account. Traditionally the client will talk to
all servers at the same time if it can't get to the initial kdc fairly >quickly. It's not obvious to me that this behavior changes with the new
code. The comments suggest that with TCP if there isn't an answer within
10 sec, it then tries all servers.
This could produce the effect of having several servers simultaneously
asking for DUO authentication, if the user doesn't respond within 10
sec. This is not a desirable result. I'm not entirely sure how this
should work, but my first inclination is to say that if a TCP connection >opens to the server, no other connection should be opened until the
timeout. At the timeout another server should be tried.
I want to preface this by saying I have no direct experience with Duo,
but we have used a number of OTP solutions with Kerberos over the years.
And out of curiousity I just took a look at the Duo API since it has
been brought up as a possible solution over the years.
I think the answer is going to be "it depends".
The normal way 2-factor works in Kerberos is that it's implemented
as a preauthentication mechanism. The KDC says, "preauth is required", provides a list of preauth mechanisms, the client picks one, and at
THAT point the second factor code is captured by the client and sent
to the KDC for verification. There is a general assumption that the
second factor verification happens quickly.
If you are using Duo with the "passcode" factor then this should be straightforward. However, if you are using Duo with a factor of "push"
or "phone", as you say it may take someone a bit to respond to that and
that may exceed the Kerberos message timeout and cause a fallover to
another KDC. We use to have this issue back when we used SecurID; the
old ACE server would hold onto a request for a second, which would cause
a failover, but a SECOND request for the same token sent by a replica
KDC to the ACE server would immediately return a "reject" code while
holding onto the first request for a second, so this caused us no end
of problems.
So, solutions? Well, one thing that pops out (but might be a fair
amount of code) is to write your own verification server that the
KDC talks to that sends the Duo requests, talks to the Duo servers
for you, and keeps tracks of requests and prevents multiple requests
from being sent to Duo if retries are encountered. I'm not sure
if there are better ideas but I would be interested in hearing
about them if there are.
I also see that Greg just said that as of 1.22 the client has much
better behavior for TCP connections, but that only helps if you ensure
that TCP is used for that connection. Is there a knob that says
you are only going to use TCP for preauth? If so, that would solve
that problem.
--Ken
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)