any way to get user's ldap dn (or part of it) as part of the ticket?

Chris Hecker checker at d6.com
Sat Aug 27 05:30:23 EDT 2016


Ah, hmm, the latest versions of these in the source repository are a 
little more clear...I need to upgrade before looking into this...

Chris

On 2016-08-27 02:28, Chris Hecker wrote:
>
> 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).
>>>


More information about the krbdev mailing list