Hi. Hi, I don't have enough time to dig into the Samba code, but I'm happy to help interface with the MIT Kerberos team on this issue.
A couple of points. First, 1.8 is in alpha test. Etienne's assumption that upstream is aware of the consequences of their changes is false. Upstream (including myself) was and remains puzzled that this change breaks Samba. We were aware it would create problems for OpenAFS but have worked with that community to provide a way to fix the problem. Second, I still don't understand what's breaking. Samba should not be relying only on DES: doing so will break against a Windows 2008 R2 domain; Microsoft lead the way in turning off DES. If Samba *needs* to be using DES and not DES+RC4 please let the Kerberos folks know, as it would really surprise us and we'd like to understand why. Second, setting allow_weak_crypto for samba seems like very much the wrong fix unless we can figure out a good reason why Samba should be using DES. It's my understanding that setting default enctypes that include both DES and RC4 should not actually produce an error: DES should be filtered out. If Samba is telling the Kerberos library that it would like to use either DES or RC4, and the Kerberos library is returning a bug, then that's a bug; please report it against libkrb5-3 and we'll expedite a fix. The only thing that should fail is either if you only enable DES enctypes or the only enctype a server and client share is DES. Since Windows *always* supports RC4, that should not be an issue for Samba. Finally, as an asside, not including aes256 decreases Samba's security against Vista, 2008 and 2008 R2 and may create interoperability problems with some configurations of 2008 and 2008 R2. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org