Re: apache virtual hosts and keytabs
On 30.09.2010 1:23, Russ Allbery wrote: In practice, you need to add HTTP/* principals for both names to the Apache keytab if they differ, and then configure mod_auth_kerb to accept any credential that's available in the keytab. Last time we did testing, Firefox did one thing and IE did the opposite thing, so you'll have substantial numbers of users in both camps. So if my hostname is machine.example.com and virtual hostname virtual.example.com I have to add both in keytab? I did try that didn't help me either. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: apache virtual hosts and keytabs
Nikolay Shopik sho...@inblock.ru writes: On 30.09.2010 1:23, Russ Allbery wrote: In practice, you need to add HTTP/* principals for both names to the Apache keytab if they differ, and then configure mod_auth_kerb to accept any credential that's available in the keytab. Last time we did testing, Firefox did one thing and IE did the opposite thing, so you'll have substantial numbers of users in both camps. So if my hostname is machine.example.com and virtual hostname virtual.example.com I have to add both in keytab? Yup. I did try that didn't help me either. Works for us. Be sure that you've set KrbServiceName to any in the mod_auth_kerb configuration (and you're using a new enough mod_auth_kerb that this is supported). -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows
Hi Still related to Kerberos for Windows , but from a development perspective.. I am working on adding GSSAPI support on TortoiseSVN ; this is done by compiling sasl and neon with GSSAPI support. This is itself was rather simple using the Kerberos for Windows SDK ; however for various reasons, I could use the SDK and had to compile the kerberos libraries from source. The problem at hand, is that when GSSAPI support for SASL is compiled the resulting saslGSSAPI.dll has some dependencies on the MIT kerberos libraries. Output of ldd is: gssapi32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/gssapi32.dll (0x1c00) krb5_32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/krb5_32.dll (0x32) comerr32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/comerr32.dll (0x3c) k5sprt32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/k5sprt32.dll (0x3d) Obviously, I do not want TortoiseSVN to require people to install Kerberos for Windows, it has to work as a standalone piece of software. If those DLLs can't be found, TSVN would silently fail. If they are indeed installed, the Network Identity Manager pops-up as required, which is great. So I also compiled those DLLs and included them in TSVN ; this however had some unfortunate consequences... TSVN is using its own version of the kerberos DLLs listed above, which seem to not use krb5.ini configured by KfW ; it relies on krb5.ini found in c:\Windows When a ticket is required, the Network Identity Manager never shows up; instead it directly fails. If I obtain a ticket with NIM, then TSV will connect fine. So the obvious question is: Assuming TSVN ships with its own compiled version of the kerberos DLLs listed above; how can I make it call NIM when required , so it perfectly integrates with any installed version of Kerberos for Windows. This is something Firefox or Thunderbird do fine... Not sure how they did it. Thank you for your help Jean-Yves Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Documentation of auth_to_local
I have been trying out Kerberos under CentOS 5.5, which claims to include
MIT kerberos version 1.6.1:
# rpm -qi krb5-server
Name: krb5-server Relocations: (not relocatable)
Version : 1.6.1 Vendor: CentOS
...
URL : http://web.mit.edu/kerberos/www/
Now, in the administrator's guide on the web at
http://web.mit.edu/Kerberos/krb5-1.4/krb5-1.4/doc/krb5-admin.html#realms%20(krb5.conf)
http://web.mit.edu/Kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#realms-_0028krb5_002econf_0029
http://web.mit.edu/Kerberos/krb5-1.7/krb5-1.7.1/doc/krb5-admin.html#realms%20(krb5.conf)
it gives the following example usage of auth_to_local:
[realms]
ATHENA.MIT.EDU = {
auth_to_local = {
RULE:[2:$1](johndoe)s/^.*$/guest/
RULE:[2:$1;$2](^.*;admin$)s/;admin$//
RULE:[2:$2](^.*;root)s/^.*$/root/
DEFAULT
}
}
However, this doesn't work for me. Even just
[realms]
BAR.EXAMPLE.COM = {
...
auth_to_local = {
DEFAULT
}
}
was rejected. sshd logs showed:
debug1: userauth-request for user candlerb service ssh-connection method
gssapi-with-mic
debug1: attempt 1 failures 1
debug1: An invalid name was supplied
Improper format of Kerberos configuration file
However, the following seems to work just fine:
[realms]
BAR.EXAMPLE.COM = {
kdc = kdc.bar.example.com:88
admin_server = kdc.bar.example.com:749
default_domain = bar.example.com
auth_to_local = RULE:[1:$...@$0](^...@foo\.example\.com$)s/@FOO.EXAMPLE.COM$//
auth_to_local = DEFAULT
}
Based on that, I think the documentation should show:
[realms]
ATHENA.MIT.EDU = {
auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/
auth_to_local = RULE:[2:$1;$2](^.*;admin$)s/;admin$//
auth_to_local = RULE:[2:$2](^.*;root)s/^.*$/root/
auth_to_local = DEFAULT
}
But is it that the version of Kerberos bundled with RedHat/CentOS is
different from the mainline MIT code?
Regards,
Brian Candler.
P.S. The hint to try a different format of auth_to_local came from
http://www.fnal.gov/docs/strongauth2003/html/krb5conf.html
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows
Jean-Yves: I would recommend that you take a look at http://github.com/secure-endpoints/heimdal-krbcompat This SDK provides implementation independence for applications with both Heimdal and MIT Kerberos. If you don't want to go this route what you need to do is to use delay loading of the GSSAPI*.DLL and avoid calling any gss functions if the library is not present. Jeffrey Altman On 9/30/2010 5:24 AM, Jean-Yves Avenard wrote: Hi Still related to Kerberos for Windows , but from a development perspective.. I am working on adding GSSAPI support on TortoiseSVN ; this is done by compiling sasl and neon with GSSAPI support. This is itself was rather simple using the Kerberos for Windows SDK ; however for various reasons, I could use the SDK and had to compile the kerberos libraries from source. The problem at hand, is that when GSSAPI support for SASL is compiled the resulting saslGSSAPI.dll has some dependencies on the MIT kerberos libraries. Output of ldd is: gssapi32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/gssapi32.dll (0x1c00) krb5_32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/krb5_32.dll (0x32) comerr32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/comerr32.dll (0x3c) k5sprt32.dll = /cygdrive/c/Program Files (x86)/MIT/Kerberos/bin/k5sprt32.dll (0x3d) Obviously, I do not want TortoiseSVN to require people to install Kerberos for Windows, it has to work as a standalone piece of software. If those DLLs can't be found, TSVN would silently fail. If they are indeed installed, the Network Identity Manager pops-up as required, which is great. So I also compiled those DLLs and included them in TSVN ; this however had some unfortunate consequences... TSVN is using its own version of the kerberos DLLs listed above, which seem to not use krb5.ini configured by KfW ; it relies on krb5.ini found in c:\Windows When a ticket is required, the Network Identity Manager never shows up; instead it directly fails. If I obtain a ticket with NIM, then TSV will connect fine. So the obvious question is: Assuming TSVN ships with its own compiled version of the kerberos DLLs listed above; how can I make it call NIM when required , so it perfectly integrates with any installed version of Kerberos for Windows. This is something Firefox or Thunderbird do fine... Not sure how they did it. Thank you for your help Jean-Yves signature.asc Description: OpenPGP digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Copying keys from one KDC to another?
I have cross-realm authentication working, and one step of this required me to do the following on both KDCs: # kadmin.local addprinc krbtgt/bar.example@foo.example.com and then type the same (long and random) password into both boxes. Ideally I would have generated a random password on one box (e.g. addprinc -randkey) and then copied it to the other, and I wondered if there is a straightforward way to do this. I could, for example, extract the principal and password into a keytab file; but is it possible to import this keytab file into the other KDC database? Maybe pasting the output from /dev/urandom into two terminal sessions is easier anyway. I just wanted to know if I was missing a trick :-) Regards, Brian. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Copying keys from one KDC to another?
On Thu, 2010-09-30 at 10:24 -0400, Brian Candler wrote: Ideally I would have generated a random password on one box (e.g. addprinc -randkey) and then copied it to the other, and I wondered if there is a straightforward way to do this. I'm not personally aware of a straightforward way to do this in MIT krb5. I think the necessary protocol features exist in kadmin; all that's needed is a kadmin command to push the contents of a keytab to a principal using the setkey RPC. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Documentation of auth_to_local
On Thu, Sep 30, 2010 at 09:14:32AM -0400, Greg Hudson wrote: That's just wrong; I've fixed it for the 1.9 admin docs. Thanks for reporting this, and apologies for the time it took to figure it out. That's OK, I learned a lot in the process :-) Regards, Brian. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Documentation of auth_to_local
On Thu, 2010-09-30 at 07:16 -0400, Brian Candler wrote:
Now, in the administrator's guide on the web at [...]
[realms]
ATHENA.MIT.EDU = {
auth_to_local = {
RULE:[2:$1](johndoe)s/^.*$/guest/
RULE:[2:$1;$2](^.*;admin$)s/;admin$//
RULE:[2:$2](^.*;root)s/^.*$/root/
DEFAULT
}
}
That's just wrong; I've fixed it for the 1.9 admin docs. Thanks for
reporting this, and apologies for the time it took to figure it out.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
list principals using ldap back end
Hi, I tried to find this in the documentation so if someone could point me in the right direction, I would appreciate it. I am trying to list all the kerberos principals created with a LDAP back end that are not in the realm container. Using kadmin list_principals only shows what is in the realm container. We have the user principals in a different cn by using -subtrees when the realm was created. It looks like kdb5_ldap_util might be able to do this? Thanks for any help with this. Kevin Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: list principals using ldap back end
Hi Kevin This should just work. kadmin and kadmin.local will list all the principals found in any subtrees that are found in the Kerberos Realm Container. You should be able to see your subtrees in the LDAP tree under the realm container using any LDAP browser. In my test tree my Kerberos Realm Container is cn=TEST.CBN,ou=kerberos,dc=test,dc=com. This DN contains two krbSubTrees attributes, ou=people,dc=test,dc=com and ou=services,dc=test,dc=com and all principals there are listed with a list_principals command in kadmin. Make sure your subtrees entries are correct. If they are not you can use the kdb5_ldap_util modify command to add/fix them. I have also had no issues directly editing these entries with an LDAP browser. Tom On 09/30/2010 03:10 PM, Kevin Longfellow wrote: Hi, I tried to find this in the documentation so if someone could point me in the right direction, I would appreciate it. I am trying to list all the kerberos principals created with a LDAP back end that are not in the realm container. Using kadmin list_principals only shows what is in the realm container. We have the user principals in a different cn by using -subtrees when the realm was created. It looks like kdb5_ldap_util might be able to do this? Thanks for any help with this. Kevin Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: list principals using ldap back end
Hi Kevin, One more thing I just thought of. Check the value for sscope (Search Scope). It should be in your Kerberos Realm Container as krbSearchScope. If this is set to 1 it will not search your subtrees. From the krb5_ldap_util man page: -sscope search_scope Specifies the scope for searching the principals under the subtrees. The possible values are 1 or one (one level), 2 or sub (subtrees). You can fix this with the krb5_ldap_util modify command or by adding/modifying this attribute in your krbRealmContainer Tom On 09/30/2010 03:10 PM, Kevin Longfellow wrote: Hi, I tried to find this in the documentation so if someone could point me in the right direction, I would appreciate it. I am trying to list all the kerberos principals created with a LDAP back end that are not in the realm container. Using kadmin list_principals only shows what is in the realm container. We have the user principals in a different cn by using -subtrees when the realm was created. It looks like kdb5_ldap_util might be able to do this? Thanks for any help with this. Kevin Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows
Hi On 30 September 2010 23:19, Jeffrey Altman jalt...@secure-endpoints.com wrote: Jean-Yves: I would recommend that you take a look at http://github.com/secure-endpoints/heimdal-krbcompat This SDK provides implementation independence for applications with both Heimdal and MIT Kerberos. If you don't want to go this route what you need to do is to use delay loading of the GSSAPI*.DLL and avoid calling any gss functions if the library is not present. Jeffrey Altman Thank you for this information. I actually found that the source of the problem was related to a missing argument when compiling. I was compiling without KRB5_KFW_COMPILE=1 Which ends to compiling with -DWITH_LEASH Since compiling with that, everything works as expected, e.g. when TortoiseSVN needs it, the Network Identity Manager pops up.. I will look at this SDK, because compiling the whole KRB5 takes forever, and ends up taking a rather significant size (over 2MB) I don't have much leeway on how to call GSSAPI, it's all done by neon and sasl ; and I don't want to have to modify those. JY Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows
On 9/30/2010 7:34 PM, Jean-Yves Avenard wrote: Hi On 30 September 2010 23:19, Jeffrey Altman jalt...@secure-endpoints.com wrote: Jean-Yves: I would recommend that you take a look at http://github.com/secure-endpoints/heimdal-krbcompat This SDK provides implementation independence for applications with both Heimdal and MIT Kerberos. If you don't want to go this route what you need to do is to use delay loading of the GSSAPI*.DLL and avoid calling any gss functions if the library is not present. Jeffrey Altman Thank you for this information. I actually found that the source of the problem was related to a missing argument when compiling. I was compiling without KRB5_KFW_COMPILE=1 Which ends to compiling with -DWITH_LEASH Since compiling with that, everything works as expected, e.g. when TortoiseSVN needs it, the Network Identity Manager pops up.. I will look at this SDK, because compiling the whole KRB5 takes forever, and ends up taking a rather significant size (over 2MB) I don't have much leeway on how to call GSSAPI, it's all done by neon and sasl ; and I don't want to have to modify those. JY You should not have to build KFW from scratch to build applications. The KFW SDK is included in the KFW installers. You want to build against that, not the source tree. Jeffrey Altman signature.asc Description: OpenPGP digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows
Hi On 1 October 2010 09:39, Jeffrey Altman jalt...@secure-endpoints.com wrote: You should not have to build KFW from scratch to build applications. The KFW SDK is included in the KFW installers. You want to build against that, not the source tree. I agree. However, the author of TortoiseSVN wants to only build against source code and not pre-compiled libraries. So unfortunately, I had no choice on the matter Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows
On 9/30/2010 7:45 PM, Jean-Yves Avenard wrote: Hi On 1 October 2010 09:39, Jeffrey Altman jalt...@secure-endpoints.com wrote: You should not have to build KFW from scratch to build applications. The KFW SDK is included in the KFW installers. You want to build against that, not the source tree. I agree. However, the author of TortoiseSVN wants to only build against source code and not pre-compiled libraries. So unfortunately, I had no choice on the matter MIT Kerberos / GSS libraries are DLLs that are shipped independently. It is not appropriate for individual software packages to distribute their own builds of the libraries. Nor should a software application be tied to a specific release of the libraries. TortoiseSVN should recognize when Kerberos/GSS is available and use it when it is and ignore it when it isn't. As a result I see no reason why TortoiseSVN should be built against MIT Kerberos source. As a user of TortoiseSVN I would be more than happy to speak with the author on this matter if he contacts me. Jeffrey Altman signature.asc Description: OpenPGP digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
