Reg: providing kerberos for multiple UPN suffix - unable to create keytab for multiple UPN's

Douglas E. Engert deengert at anl.gov
Tue Mar 19 11:59:40 EDT 2013



On 3/19/2013 5:50 AM, pvbalachandar wrote:
> Hello all,
>
>
> I really need your guys help. Currently I have provided Kerberos
> authentication to Shibboleth Identity Provider to access my Service provider
> page.

Are you using the standard user/password login with the kerberos username and
password or the java-idp-kerberos-login-handler?

The user/name and password use the Java krb5 support and request
a TGT from the KDC for the user. It then may request a service ticket
for the service. In this case the IDP will have to have a keytab file
file the IDP's service principal and key.

In the java-idp-kerberos-login-handler its really GSSAPI and the
IDP will also need a keytab and principal.

So in either case you are talking cross realm, forest or cross forest
trust. If it can be setup, between the domains, then the keytab
file would only need a single service principal entry in the keytab.

It might be possible for the IDP's keytab file to have service
principal setup for each of the domains. This would require code
changes to the java-idp-kerberos-login-handler.

>
> I am very well aware that Kerberos does not support multiple UPN suffixes.
> But I am really in a situation to provide Kerberos for multiple UPN
> suffixes. Is there any alternative to achieve this?
>
>
> I am going to have around 100 domains as UPN suffix to my primary domain and
> authenticate users. My primary domain has got Kerberos access, but accounts
> with different UPN suffix is not getting authenticated.

I will assume that the KDC is AD, since you are using the terms UPN, domain
and account.

Are these domains in a forest?
Are they under your control?
Or are they independent customer domains?

The issues is who trusts who.

Having to have each domain setup a service principal name for your
IDP would require the domain admin to create it.

If these are independent customer domains, they may not be willing
to allow Kerberos access from outside, and don't want their users
sending Kerberos passwords to your IDP. They might be willing to
create a service principal for IDP. (but I doubt it.)

We run the java-idp-kerberos-login-handler but for use with our
internal domain. I don't know if java-idp-kerberos-login-handler can
support a keytab with multiple service principals from different realms.
It might with some code changes.

It sounds like you are trying to use Shibboleth in a way it was
designed to replace.

The point of Shibboleth, is you as a SP vendor run an SP,
and let your customer sites run an IDP, you exchange metadata
(or let a federation do that for you) to authenticates the users
from that site to your site. It avoids many if the Kerberos cross
realm issues and trust issues with outside sites.

Do any of the sites run ADFS? It can act as a IDP for that site.
Are any members of InCommon? https://incommon.org

If all your 100 domains do not run an IDP, you may need an IDP
or some other login method for the users from those sites.
As those sites get an IDP, you transition users from those sites
to use their own IDP.

>
>
> Please help me to resolve this issue. Hope you guys can help me in it.
>

As you can tell, I don't think you are trying to using Shibboleth
as it was designed to be used.

You may also want to post your question of the users at shibboleth.net
list.

>
>
> Regards
>
> Prasanna V B  |  Software Developer
>
>
>
>
> --
> View this message in context: http://kerberos.996246.n3.nabble.com/Reg-providing-kerberos-for-multiple-UPN-suffix-unable-to-create-keytab-for-multiple-UPN-s-tp36765.html
> Sent from the Kerberos - Dev mailing list archive at Nabble.com.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


More information about the krbdev mailing list