[19462] in Kerberos_V5_Development
Re: any way to get user's ldap dn (or part of it) as part of the
daemon@ATHENA.MIT.EDU (Chris Hecker)
Sat Aug 27 05:28:24 2016
To: krbdev@mit.edu
From: Chris Hecker <checker@d6.com>
Message-ID: <1f378641-9d71-f0a2-7de9-e9421240ba46@d6.com>
Date: Sat, 27 Aug 2016 02:28:12 -0700
MIME-Version: 1.0
In-Reply-To: <40174170-d1a5-e846-b664-c30f21302d72@d6.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
As a followup to this, after looking at the greet code...which piece of
code goes where? There are three directories, greet, greet_client, and
greet_server. It seems like greet_client is for passing information
along from my client to my service via the ap-req, which I don't need?
Chris
On 2016-08-25 23:42, Chris Hecker wrote:
>
> Yeah, I want the UUID on the service that gets tickets from the clients
> (so I can stop using the username as a db key, which was just a terrible
> idea but hey, I was young).
>
> So, to be clear, the client (my game) logs into the KDC, requests a
> ticket to the service (the lobby server), and then logs into the lobby
> server using this ticket. I'd like the lobby server to be able to get
> the UUID (from the kdb LDAP backend) out of the ticket without talking
> to the KDC/LDAP machine again over the wire. I don't particularly care
> if the client can decrypt the UUID, but I guess it's slightly better if
> they can't (which it sounds like is the case with authdata, it's
> encrypted with the service key)?.
>
> It looks like the greet client and server stuff are the things to look
> at here?
>
> Chris
>
>
>
> On 2016-08-25 23:32, Greg Hudson wrote:
>> On 08/26/2016 02:29 AM, Greg Hudson wrote:
>>> Microsoft's PAC is visible to the server, not the client.
>>
>> Oops, I misread your question. You want this information in the server,
>> so yes, you want authdata. Ignore everything I said about using padata.
>>
>> We do have an authdata plugin interface, but unfortunately it's
>> unfinished and not public. Still, it's probably better than modifying
>> the code.
>>
>> Authdata is encrypted in the AS-REP, so you don't have to worry about
>> protecting the value. Negative authdata types are reserved for
>> unregistered use (RFC 4120 section 5.2.6).
>>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
