You only require a krb524d, fakeka, etc. if you are attempting to support clients that cannot make use of Kerberos 5-based tokens. What clients are you attempting to support?
MIT KFW does not ship with any server side daemons. The daemon you would want to build is a krb524d.exe and you would want to run it on the domain controllers using the keytab option. You could of course run a second realm and establish the cross-realm trust. However, that is more work. Unless you really have no control over the clients and must support the use of "kauth" instead of even "kerberos 4" there is no longer a need to do so. Jeffrey Altman theo van den bout wrote:
Hi (Jeffrey) Thanks for the info, but i still have a lot of questions. Am I right in assuming that i will need krb524, fakeka and the ka-forwarder, and that both krb524 & fakeka have to run on the KDC which, in my case, is a Windows machine? Krb524/fakeka-for-windows doesn't seem easily available. I found k524init.exe & krb524.dll in the KfW package but i'm not sure if or how to use them stand-alone. Would it be easier to have a second MIT kerberos realm ( implemented on linux and running k524 + fakeka ) and establish cross realm trust with ADS? TheoTheo:From the perspective of OpenAFS, Active Directory is just a Kerberos 5KDC. The reasons there were issues in the past were: * AD issues DES-CBC-MD5 tickets instead of DES-CBC-CRC * AD issues tickets that are longer than 344 bytes In OpenAFS 1.4, support was added for DES-CBC-MD5 and DES-CBC-MD4 plus the restriction on ticket length was increased to 14000 bytes (which is documented as the largest ticket AD will issue.) Therefore, in order to use a Windows Domain as the Kerberos 5 realm for a cell you should follow Ken Hornstein's migration guide with the following exceptions: * the Kerberos 5 keytab file is generated with KTUTIL.EXE * the Active Directory account used for the service principal must be marked DES only * the kvno of the new Kerberos 5 key must not be the same as any of your pre-existing keys in the AFS keyfile Use "asetkey" from the migration guide (this is not built in 1.4.0 but will be included in 1.4.1) to import the Kerberos 5 key into the AFS key file on the servers. The AFS clients will require the aklog tool (built as part of 1.4.0 when one of the krb5 configure options is specified) and a proper /etc/krb5.conf file. (as described in the migration guide.) Jeffrey Altman theo van den bout wrote:Hi Guys The release announcement of the new 1.4 version mentions " This release allows Kerberos 5 KDCs including Microsoft Active Directory to be the source of AFS client authentication. " And that's precisely what i need... but i could do with a bit more info. :) Can somebody please send me in the right direction? Sofar i always used the kas-server. If i: * leave out the kas-server * configure /etc/krb5.conf * add an afs principal (from ADS) to /etc/keytab would that be sufficient? ( I'm not trying to migrate, I just want it up and running. ) Do i need any non-default configure/compile options? I'm using a linux server and linux client for testing. ( SuSE 10.0 ) The best Theo _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
smime.p7s
Description: S/MIME Cryptographic Signature
