AFS token issue in samba 3.5.5? [solution]

[Eric Chris Garrison]

  I will try to create a patch and submit it as soon as I get some time, 
though I'll have to figure out the proper procedure.  I'm a bit swamped 
right now, so it won't be immediate, but if you follow my directions in 
the fixed reply, it should work.

It's nice to know someone else out there is using this... we rather rely 
on it here.

Chris

On 9/18/10 4:21 AM, Gémes Géza wrote:
> 2010-09-18 08:48 keltezéssel, Volker Lendecke írta:
>> On Sat, Sep 18, 2010 at 08:21:47AM +0200, Gémes Géza wrote:
>>
>>> Could you post your patch somewhere. Or give your assigned (by bugzilla)
>>> bug number. I also plan to upgrade to 3.5.5. (and also use fake-kaserver)
>>>
>> BTW, I'm really surprised that this is still being used. It
>> was meant at the time as a pretty specialized hack... :-)
>>
>> Volker
>>
> Until there is something better IMHO it is the best fail-back solution.
> At our site we have a samba3 (with ldap backend) domain, a heimdal
> kerberos (with the same ldap backend) realm, and an openafs data store.
> The windows clients authenticate to the samba3 domain, and by integrated
> logon they get kerberos tickets and afs tokens, and then the logon
> scripts are able to map the afs dirs at the correct drive letters. If
> integrated logon or other afs components fail the logon scripts are
> trying to map a share from the logon server (here comes the
> fake-kaserver part into action). Btw. the netlogon share is also in afs
> (replication is a non-issue ;-) ). So I think keeping fake-kaserver and
> vfs-afsacl functional is crucial for sites where there is a
> samba-openafs mixed infrastructure. The only better aproach I could
> think about would be to "convince" windows machines to do proxiable
> kerberos authentication to samba even in NT4 domain mode. However I'm
> afraid that is way harder to implement than to keep fake-kaserver alive.
>
> Geza