Kerberos cross-realm with AD

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi there.

I have a mac os server running MIT krb5 v1.7 ; it's been working great
for a while now. The realm used is M.DOMAIN.COM

I am in the process of setting up a Windows 2008 server with Active
Directory. The name of the new domain will be MEL.DOMAIN.COM

I'm trying to understand how I can configure the MIT kerberos server
to accept realm coming from AD.

I have read the MIT documentation and created on both kdc
krbtgt/[hidden email]
krbtgt/[hidden email]

I then edited the kerberos krb5.conf with the appropriate capaths and
configured AD to accept M.DOMAIN.COM issued tickets.

What I'm unclear about however, is do I need to configure all kerberos
clients in a similar fashion or is this done only on the 2 kdcs ?

In particular, I have a FreeBSD server running MIT krb5 1.9 with
mod_auth_kerb . It is set to accept M.DOMAIN.COM realm . Do I need to
explicitely configures it to accept MEL.DOMAIN.COM realm, or because
the two kdcs are configured to accept each other it will then be
automatic ?

Thank you
Jean-Yves
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi there.

Providing more information in the hope that someone will be able to help:

This is the process I've followed.

In Windows 2008 (MEL.DOMAIN.COM domain):

Started Active Directory Domain and Trusts
Right click on the domain name -> Properties. Select Trusts -> New Trusts
Entered M.DOMAIN.COM ; made it two ways ; non-transitive ; typed the
password. Validate..

On MIT kdc machine (M.DOMAIN.COM realm)

kadmin.local:
kadmin.local:  ank +requires_preauth krbtgt/[hidden email]
WARNING: no policy specified for krbtgt/[hidden email];
defaulting to no policy
Enter password for principal "krbtgt/[hidden email]":
Re-enter password for principal "krbtgt/[hidden email]":
Principal "krbtgt/[hidden email]" created.
kadmin.local:  ank +requires_preauth krbtgt/[hidden email]
WARNING: no policy specified for krbtgt/[hidden email];
defaulting to no policy
Enter password for principal "krbtgt/[hidden email]":
Re-enter password for principal "krbtgt/[hidden email]":
Principal "krbtgt/[hidden email]" created.

In the above, I used the same password (32 random characters) as I
used in Windows 2008 server.

Edited /etc/krb5.conf on the kdc as follow:
[libdefaults]
        default_realm = M.DOMAIN.COM
[realms]
        M.DOMAIN.COM = {
                admin_server = m.domain.com
                kdc = m.domain.com
        }
        MEL.DOMAIN.COM = {
                admin_server = ad.domain.com
                kdc = ad.domain.com
        }
[domain_realm]
        domain.com = M.DOMAIN.COM
        .domain.com = M.DOMAIN.COM
        .m.domain.com = M.DOMAIN.COM
        .mel.domain.com = MEL.DOMAIN.COM

[capaths]
    MEL.DOMAIN.COM.COM = {
        M.DOMAIN.COM = .
    }

    M.DOMAIN.COM = {
         MEL.DOMAIN.COM = .
    }

---

On the web server using mod_auth_kerb:
I set the /etc/krb5.conf as above...

People with a M.DOMAIN.COM ticket, can connect fine as that's what it
is configured for.

On my PC ; I then got a ticket as [hidden email] ;
and try to connect to the web server ; and it fails prompting me for a
username/password (it's setup to accept any user with kerberos
authtype)

On the KDC; in the log I see:
Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,  <unknown
client> for HTTP/[hidden email], Decrypt
integrity check failed
Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,  <unknown
client> for HTTP/[hidden email], Decrypt
integrity check failed
Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,  <unknown
client> for HTTP/[hidden email], Decrypt
integrity check failed
Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,  <unknown
client> for HTTP/[hidden email], Decrypt
integrity check failed

Which lead me to believe that there's an incorrect password set
somewhere... but which one ?

I'm a tad puzzled about what's going on..
If someone could shed some lights it would be greatly appreciated.

Thank you
Jean-Yves
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Brian Candler
In reply to this post by Jean-Yves Avenard-2
On Mon, Feb 07, 2011 at 11:36:50AM +1100, Jean-Yves Avenard wrote:

> I have read the MIT documentation and created on both kdc
> krbtgt/[hidden email]
> krbtgt/[hidden email]
>
> I then edited the kerberos krb5.conf with the appropriate capaths and
> configured AD to accept M.DOMAIN.COM issued tickets.
>
> What I'm unclear about however, is do I need to configure all kerberos
> clients in a similar fashion or is this done only on the 2 kdcs ?
>
> In particular, I have a FreeBSD server running MIT krb5 1.9 with
> mod_auth_kerb . It is set to accept M.DOMAIN.COM realm . Do I need to
> explicitely configures it to accept MEL.DOMAIN.COM realm, or because
> the two kdcs are configured to accept each other it will then be
> automatic ?

Depends what you mean.

The *authentication* should just work. Someone in MEL.DOMAIN.COM will be
able to get a ticket for host/[hidden email], which that server
will be able to decrypt using its M.DOMAIN.COM keytab.

However you then may have an issue with *authorization*. For example, if you
ssh as "user" to freebsd.server, by default sshd will only authorize the
login for someone with a ticket "[hidden email]" (i.e.  the realm of the
server itself)

Solution 1: you can put [hidden email] in ~user/.k5login (or indeed,
any kerberos principals you want to be able to login as 'user').  Easy to
do, but doesn't scale well if you keep having to add and remove users across
all hosts.

Solution 2: you can map all [hidden email] to [hidden email]

In krb5.conf (on the FreeBSD server) this would be something like:

[realms]
 M.DOMAIN.COM = {
  auth_to_local = RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$//
  auth_to_local = DEFAULT
 }

WARNING: not tested. You need to triple-check that's right, as it could open
you up to various holes if not correct.  The syntax is interesting, to say
the least.  Also, you need to make sure that [hidden email] and
[hidden email] are never two different people.  But it's a one-off
config change on each host.

Solution 3: I don't know, maybe other people on this list have some ideas?

Regards,

Brian.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Simo Sorce
On Mon, 7 Feb 2011 18:12:37 +0000
Brian Candler <[hidden email]> wrote:

> Solution 2: you can map all [hidden email] to [hidden email]
>
> In krb5.conf (on the FreeBSD server) this would be something like:
>
> [realms]
>  M.DOMAIN.COM = {
>   auth_to_local =
> RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$//
> auth_to_local = DEFAULT }
>
> WARNING: not tested. You need to triple-check that's right, as it
> could open you up to various holes if not correct.  The syntax is
> interesting, to say the least.  Also, you need to make sure that
> [hidden email] and [hidden email] are never two different
> people.  But it's a one-off config change on each host.

If you want separate users you can also create users with a
prefix/suffix as part of the user name for the "foreign" users:

user-MEL or MEL.DOMAIN.COM-username

They may not look pretty but would get the job done w/o risk of having
collisions as long as the main domain username assignment follows
minimal rules.

First form:
RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$/-MEL/

Second form:
RULE:[1:$1@$0](^.*@.*$)s/(^.*)@(.*$)/\2-\1/

I haven't tested this last one, so I am not sure the syntax is correct,
but it should be possible to get to a working syntax.

Simo.

--
Simo Sorce * Red Hat, Inc * New York
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Tom Parker-10
We have a similar scenario with user collisions in a cross realm
environment.  We are using fully qualified Principal names as usernames
on all our servers (stored in ldap and accessed with nss_ldap)

<user@REALM> is the user that is logged in.  Not just <user>

Our auth-to-local rules are:

                 auth_to_local = RULE:[1:$1@$0]
                 auth_to_local = RULE:[2:$1@$0]

This is annoying to anyone who has to type their password but with
GSSAPI and a good .ssh/config file our complaints have gone away

Tom


On 02/07/2011 01:48 PM, Simo Sorce wrote:

> On Mon, 7 Feb 2011 18:12:37 +0000
> Brian Candler<[hidden email]>  wrote:
>
>> Solution 2: you can map all [hidden email] to [hidden email]
>>
>> In krb5.conf (on the FreeBSD server) this would be something like:
>>
>> [realms]
>>   M.DOMAIN.COM = {
>>    auth_to_local =
>> RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$//
>> auth_to_local = DEFAULT }
>>
>> WARNING: not tested. You need to triple-check that's right, as it
>> could open you up to various holes if not correct.  The syntax is
>> interesting, to say the least.  Also, you need to make sure that
>> [hidden email] and [hidden email] are never two different
>> people.  But it's a one-off config change on each host.
> If you want separate users you can also create users with a
> prefix/suffix as part of the user name for the "foreign" users:
>
> user-MEL or MEL.DOMAIN.COM-username
>
> They may not look pretty but would get the job done w/o risk of having
> collisions as long as the main domain username assignment follows
> minimal rules.
>
> First form:
> RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$/-MEL/
>
> Second form:
> RULE:[1:$1@$0](^.*@.*$)s/(^.*)@(.*$)/\2-\1/
>
> I haven't tested this last one, so I am not sure the syntax is correct,
> but it should be possible to get to a working syntax.
>
> Simo.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Douglas E. Engert
In reply to this post by Jean-Yves Avenard-2


On 2/6/2011 11:15 PM, Jean-Yves Avenard wrote:

> Hi there.
>
> Providing more information in the hope that someone will be able to help:
>
> This is the process I've followed.
>
> In Windows 2008 (MEL.DOMAIN.COM domain):
>
> Started Active Directory Domain and Trusts
> Right click on the domain name ->  Properties. Select Trusts ->  New Trusts
> Entered M.DOMAIN.COM ; made it two ways ; non-transitive ; typed the
> password. Validate..
>
> On MIT kdc machine (M.DOMAIN.COM realm)
>
> kadmin.local:
> kadmin.local:  ank +requires_preauth krbtgt/[hidden email]
> WARNING: no policy specified for krbtgt/[hidden email];
> defaulting to no policy
> Enter password for principal "krbtgt/[hidden email]":
> Re-enter password for principal "krbtgt/[hidden email]":
> Principal "krbtgt/[hidden email]" created.
> kadmin.local:  ank +requires_preauth krbtgt/[hidden email]
> WARNING: no policy specified for krbtgt/[hidden email];
> defaulting to no policy
> Enter password for principal "krbtgt/[hidden email]":
> Re-enter password for principal "krbtgt/[hidden email]":
> Principal "krbtgt/[hidden email]" created.
>
> In the above, I used the same password (32 random characters) as I
> used in Windows 2008 server.
>
> Edited /etc/krb5.conf on the kdc as follow:
> [libdefaults]
>          default_realm = M.DOMAIN.COM
> [realms]
>          M.DOMAIN.COM = {
>                  admin_server = m.domain.com
>                  kdc = m.domain.com
>          }
>          MEL.DOMAIN.COM = {
>                  admin_server = ad.domain.com
>                  kdc = ad.domain.com
>          }
> [domain_realm]
>          domain.com = M.DOMAIN.COM
>          .domain.com = M.DOMAIN.COM
>          .m.domain.com = M.DOMAIN.COM
>          .mel.domain.com = MEL.DOMAIN.COM
>
> [capaths]
>      MEL.DOMAIN.COM.COM = {
>          M.DOMAIN.COM = .
>      }
>
>      M.DOMAIN.COM = {
>           MEL.DOMAIN.COM = .
>      }
>
> ---
>
> On the web server using mod_auth_kerb:
> I set the /etc/krb5.conf as above...
>
> People with a M.DOMAIN.COM ticket, can connect fine as that's what it
> is configured for.
>
> On my PC ; I then got a ticket as [hidden email] ;

Is you PC Windows? Is it in a domain? If so which domain.
Did you get the ticket using the Windows kerberos, or some other kerberos?

Is the browser IE or some other browser using non-windows Kerberos?

(Windows builtin Kerberos does not use the krb5.conf, and so does
cross realm a little differently.)

> and try to connect to the web server ; and it fails prompting me for a
> username/password (it's setup to accept any user with kerberos
> authtype)
>
> On the KDC; in the log I see:
> Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
> 17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,<unknown
> client>  for HTTP/[hidden email], Decrypt
> integrity check failed

This looks strange, as the server4-2.mel.domain.com should be in the
MEL.DOMAIN.COM realm and the client should not be sending a request
to the M.DOMAIN.COM realm.


But the Decrypt integrity check failed would also imply that it
found a key to use, but the decryption did not work. This may be
a salt issue. If you set up cross-realm to use RC4, it does not
use a salt and that might make take one factor out of the loop.

A wireshark trace run on the client could help see what is going on.


> Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
> 17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,<unknown
> client>  for HTTP/[hidden email], Decrypt
> integrity check failed
> Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
> 17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,<unknown
> client>  for HTTP/[hidden email], Decrypt
> integrity check failed
> Feb 07 16:10:54 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
> 17 16 23 1 3 2}) 192.168.0.108: PROCESS_TGS: authtime 0,<unknown
> client>  for HTTP/[hidden email], Decrypt
> integrity check failed
>
> Which lead me to believe that there's an incorrect password set
> somewhere... but which one ?
>
> I'm a tad puzzled about what's going on..
> If someone could shed some lights it would be greatly appreciated.
>
> Thank you
> Jean-Yves
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi

Thank you all for your answers.

At this stage I'm only interested to pass the authentication phase ;
for authorisation I have a plan already (using ldap)

On 8 February 2011 07:45, Douglas E. Engert <[hidden email]> wrote:


>
> Is you PC Windows? Is it in a domain? If so which domain.

It is a windows PC, however it's not on any domain.

> Did you get the ticket using the Windows kerberos, or some other kerberos?

Using MIT Kerberos for PCs.

>
> Is the browser IE or some other browser using non-windows Kerberos?

That's using Firefox.

I get the same behaviour connecting from a mac , also with Firefox

However, someone who replied directly to me gave me a great hint and
suggested that the MIT kdc may have been configured to use AES by
default ; and sure enough:
kadmin.local:  getprinc krbtgt/[hidden email]
Principal: krbtgt/[hidden email]
Expiration date: [never]
Last password change: Mon Feb 07 15:57:45 EST 2011
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Feb 07 15:57:45 EST 2011 (root/[hidden email])
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 9
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, ArcFour with HMAC/md5, no salt
Key: vno 1, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
Key: vno 1, DES cbc mode with RSA-MD5, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

So in Windows Sever, domain & trust , I checked the "the other domain
supports Kerberos AES encryption"

and now when connecting I see on the M.DOMAIN.COM kdc:
Feb 08 09:02:10 m.domain.com krb5kdc[75](info): TGS_REQ (7 etypes {18
17 16 23 1 3 2}) 60.242.40.141: ISSUE: authtime 1297115394, etypes
{rep=23 tkt=16 ses=18}, [hidden email] for
HTTP/[hidden email]

And no more Decrypt integrity check failed

Now if fails somewhere else ; and on the web server I see:
[Tue Feb 08 09:13:29 2011] [error] [client 1.2.3.4] gss_acquire_cred()
failed: Unspecified GSS failure.  Minor code may provide more
information (, No key table entry found for
HTTP/[hidden email])

So it would seem the keytab on the web server running mod_auth_kerb
will also need a realm created on the new MEL.DOMAIN.COM kdc ..

Jean-Yves
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
On 8 February 2011 09:36, Jean-Yves Avenard <[hidden email]> wrote:
> Now if fails somewhere else ; and on the web server I see:
> [Tue Feb 08 09:13:29 2011] [error] [client 1.2.3.4] gss_acquire_cred()
> failed: Unspecified GSS failure.  Minor code may provide more
> information (, No key table entry found for
> HTTP/[hidden email])
>
> So it would seem the keytab on the web server running mod_auth_kerb
> will also need a realm created on the new MEL.DOMAIN.COM kdc ..

I found the reasoning behind this one.

In the /etc/krb5.conf I had:
Ah , as I was writing this I came with another idea ;
in /etc/krb5.conf I had:

[domain_realm]
 .domain.com = M.DOMAIN.COM
 domain.com = M.DOMAIN.COM
 .mel.domain.com = MEL.DOMAIN.COM

And sure enough, removing that last line ; error in apache logs are
gone, and it doesn't try to use
HTTP/[hidden email] anymore.

It still fails (with either Unspecified GSS failure.  Minor code may
provide more information (, Decrypt integrity check failed) ; or
Unspecified GSS failure.  Minor code may provide more information (,
Wrong principal in request)

; but I'm progressing. I'm now unsure if the remaining error is only
related to mod_auth_kerb or kerberos in general.


Thank you all for your help.. Made lots of progress today

Jean-Yves

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
In reply to this post by Brian Candler
Hi

On 8 February 2011 05:12, Brian Candler <[hidden email]> wrote:
> The *authentication* should just work. Someone in MEL.DOMAIN.COM will be
> able to get a ticket for host/[hidden email], which that server
> will be able to decrypt using its M.DOMAIN.COM keytab.

So in reference to authentication only.

The krb5.conf on the FreeBSD machine doesn't need to be told about
MEL.DOMAIN.COM whatsoever? and the existing configuration for the
M.DOMAIN.COM realm is all that is required and can be left untouched ?

JY
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi there..

Interestingly ; I have now reverted to kerberos 1.7 (I had avoided
upgrading to 1.8 earlier as I couldn't make it work when both 1.7 and
1.6 worked just fine. 1.9 seemed to have worked all fine until now).

Downgrading to 1.7 and my cross-ream issues are gone ; only problem
now is that I see in the log:
[Tue Feb 08 16:45:00 2011] [notice] [client 1.2.3.4]
krb5_aname_to_localname() found no mapping for principal
[hidden email]

I added in the krb5.conf

[realms]
 M.DOMAIN.COM = {
  kdc = m.domain.com
  admin_server = m.domain.com
  default_domain = m.domain.com
 }

 MEL.DOMAIN.COM = {
  kdc = ad.domain.com
  admin_server = ad.domain.com
  default_domain = ad.domain.com
  auth_to_local = RULE:[1:$1@$0](.*@.*DOMAIN\.COM$)s/@.*//
 }

from what I could read in the documentation, but this still doesn't work.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi

On 8 February 2011 16:49, Jean-Yves Avenard <[hidden email]> wrote:
>  auth_to_local = RULE:[1:$1@$0](.*@.*DOMAIN\.COM$)s/@.*//

Found the answer, this rule is only read in the principal realm

Now, why I get the whole thing to work with kerberos 1.7 but not 1.9
is another mystery. But at this stage I think I would look any deeper.

Finally got it to work !

Jean-Yves

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Brian Candler
In reply to this post by Jean-Yves Avenard-2
On Tue, Feb 08, 2011 at 09:36:48AM +1100, Jean-Yves Avenard wrote:
> At this stage I'm only interested to pass the authentication phase ;
> for authorisation I have a plan already (using ldap)

You have a solution for mapping kerberos identity to system username via
ldap? If so I'd be very interested to see it.

Regards,

Brian.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Brian Candler
In reply to this post by Jean-Yves Avenard-2
On Tue, Feb 08, 2011 at 01:32:21PM +1100, Jean-Yves Avenard wrote:
> So in reference to authentication only.
>
> The krb5.conf on the FreeBSD machine doesn't need to be told about
> MEL.DOMAIN.COM whatsoever?

Correct.

On the client side: you need to know about the MEL.DOMAIN.COM (obviously),
but also the domain_realm rules to map the server's DNS domain to realm
M.DOMAIN.COM, and also the location of the KDCs for M.DOMAIN.COM (so that it
can contact the KDC to get the correct cross-realm ticket).  Or you can
publish that info in the DNS using TXT and SRV records.

The server side needs only to know about M.DOMAIN.COM, and only needs a
keytab entry for the M.DOMAIN.COM KDC. The client will have already obtained
a ticket from the M.DOMAIN.COM KDC, encrypted with the correct key.

Regards,

Brian.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Brian Candler
In reply to this post by Jean-Yves Avenard-2
On Tue, Feb 08, 2011 at 04:49:06PM +1100, Jean-Yves Avenard wrote:

> [realms]
>  M.DOMAIN.COM = {
>   kdc = m.domain.com
>   admin_server = m.domain.com
>   default_domain = m.domain.com
>  }
>
>  MEL.DOMAIN.COM = {
>   kdc = ad.domain.com
>   admin_server = ad.domain.com
>   default_domain = ad.domain.com
>   auth_to_local = RULE:[1:$1@$0](.*@.*DOMAIN\.COM$)s/@.*//
>  }
>
> from what I could read in the documentation, but this still doesn't work.

As I understand it, you need the auth_to_local rule(s) under M.DOMAIN.COM
(the server's realm), not the client realm.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
In reply to this post by Brian Candler
Hi

On 8 February 2011 21:02, Brian Candler <[hidden email]> wrote:
> You have a solution for mapping kerberos identity to system username via
> ldap? If so I'd be very interested to see it.

Yes, for apache..

I have patched the mod_authz_ldap a while ago in order to first
simulate what apple did with their Open Directory and multiple-aliases
per account.
I then patched mod_auth_kerberos so it could be used for both kerberos
authentication and if not working default to basic authtype

So ultimately, mod_auth_kerb provides the authentication side of
things and mod_auth_ldap provides the authorisation side.

I can provide you with the various mods if you want.

JY
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Brian Candler
On Tue, Feb 08, 2011 at 10:04:14PM +1100, Jean-Yves Avenard wrote:
> On 8 February 2011 21:02, Brian Candler <[hidden email]> wrote:
> > You have a solution for mapping kerberos identity to system username via
> > ldap? If so I'd be very interested to see it.
>
> Yes, for apache..

Oh I see. Yes, mod_authnz_ldap (apache 2.2) should do the trick; the only
problem I found with it was that I couldn't use kerberos to
authenticate/encrypt the webserver-to-LDAP communication.  I never got round
to patching that.

> I then patched mod_auth_kerberos so it could be used for both kerberos
> authentication and if not working default to basic authtype

apache 2.2 has that already:

    KrbMethodK5Passwd On

will fallback to basic auth, and then check the username/password against
the KDC.

Were your mods for Apache <=2.0 ?

Regards,

Brian.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi

On 8 February 2011 22:17, Brian Candler <[hidden email]> wrote:

>    KrbMethodK5Passwd On
>
> will fallback to basic auth, and then check the username/password against
> the KDC.

Not quite.

It does fall back to basic ; but not to the basic provided by
mod_authz_ldap or any other authz_xxx for that matter;
KrbMethodK5Passwd handles it all and as you configured apache with
AuthType kerberos ; none of the remaining mod_auth_xx works because
those expect apache to be in mode AuthType basic. In the flow of
apache module; when mod_auth_kerb isn't authoritative it will only
call other authentication module compatible with the AuthType of the
module on top of the stack : here mod_auth_kerb.

So apache does something like:
mod_auth_kerb -> basic ; got authentication going. Then it tries to
check what other authorisation/authentication modules are available
with AuthType kerberos as apache can not mix authentication type (I
read that the next version of apache would have a work around for
this, but it's been years since they talked about it)

make sense?

What I wanted here is :

use kerberos for authentication ; if authentication works -> authz_ldap
if kerberos failed: continue to auth_ldap -> authz_ldap

This provides far greater flexibility and let me handle both full
kerberos authentication ; or for users with no kerberos at all, it
falls back to plain ldap authentication with the flexibility that
comes with it.

My mods are for apache 2.2 ; mod_auth_ldap was completely rewritten
unfortunately in 2.2 and it is very different with earlier version of
apache which had two distincts ldap modules: one for authentication,
one for authorisation

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Brian Candler
On Tue, Feb 08, 2011 at 11:34:55PM +1100, Jean-Yves Avenard wrote:

> On 8 February 2011 22:17, Brian Candler <[hidden email]> wrote:
>
> >    KrbMethodK5Passwd On
> >
> > will fallback to basic auth, and then check the username/password against
> > the KDC.
>
> Not quite.
>
> It does fall back to basic ; but not to the basic provided by
> mod_authz_ldap or any other authz_xxx for that matter;

Ah, I hadn't tried that, and thank you for your explanation. Sounds like
"KrbAuthoritative off" was intended to work the way you describe, but
doesn't in practice.

> My mods are for apache 2.2

Worth submitting upstream?

Regards,

Brian.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Jean-Yves Avenard-2
Hi

On 9 February 2011 00:17, Brian Candler <[hidden email]> wrote:

> Ah, I hadn't tried that, and thank you for your explanation. Sounds like
> "KrbAuthoritative off" was intended to work the way you describe, but
> doesn't in practice.

Yeah it took me a while to understand why it didn't work as expected,
and the flow of apache with auth module is puzzling ; you can't do
fall-back either, like say starting with digest and if it fails go
back to basic.

> Worth submitting upstream?

I did...
both the mod_auth_kerb and the apache mod_authz_ldap (ticket 42561,
it's an extension of an existing ticket)
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos cross-realm with AD

Russ Allbery
In reply to this post by Brian Candler
Brian Candler <[hidden email]> writes:
> On Tue, Feb 08, 2011 at 11:34:55PM +1100, Jean-Yves Avenard wrote:

>> It does fall back to basic ; but not to the basic provided by
>> mod_authz_ldap or any other authz_xxx for that matter;

> Ah, I hadn't tried that, and thank you for your explanation. Sounds like
> "KrbAuthoritative off" was intended to work the way you describe, but
> doesn't in practice.

It's very difficult to get Apache auth modules to stack in any sort of
useful fashion.  It doesn't help that Apache server hooks are almost
completely undocumented.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos