Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Osipov, Michael
Hi folks,

we are experiencing a problem with an insufficient Kerberos setup on Active Directory
side which can be solved on Windows-side with Kerberos Forest Search Order [1].
What Windows basically does is to traverse a list of Kerberos realms to obtain a
service ticket for a specific SPN where a forest (realm) feels responsible for.

Let me go in detail with a realworld example:

Two forests (realms): AD001.COMPANY.NET and COMPANY.NET whereas the latter has 20
subrealms, e.g., OLD4.COMPANY.NET.
Client account: [hidden email]
Target server is hostabc.ad001.company.net, but also has the A record
app.workspace.company.com, and of course the SPN HTTP/app.workspace.company.com.

Now both forest are set to be responsible for DNS namespace company.com.
So when [hidden email] issues a TGS-REQ to OLD4.COMPANY.NET for
HTTP/app.workspace.company.com it receives "Server not found in Kerberos database"
which makes sense here. Using a client principal from AD001.COMPANY.NET works
flawlessly. So KFSO would traverse AD001.COMPANY.NET too for the OLD1.COMPANY.NET
client principal on Windows with SSPI.

MIT Kerberos isn't capable to make use of such a logic because there is none. What
I have done is to define "app.workspace.company.com = AD001.COMPANY.NET" in the
[domain_realm], but I don't like this because to do this for every single target I
want to access and on every single server we have in our server room.

Is there a better way to solve this issue?

FWIW: We are running MIT Kerberos 1.13.x/1.15.x on FreeBSD, HP-UX and RHEL6.
Wirshark pcaps are available privately.

Best regards,

Michael

[1] https://technet.microsoft.com/de-de/library/configure-kerberos-forest-search-order-kfso(v=ws.10).aspx

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

Re: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Sean Elble
On Mar 15, 2017, at 8:15 AM, Osipov, Michael <[hidden email]> wrote:

>
> Hi folks,
>
> we are experiencing a problem with an insufficient Kerberos setup on Active Directory
> side which can be solved on Windows-side with Kerberos Forest Search Order [1].
> What Windows basically does is to traverse a list of Kerberos realms to obtain a
> service ticket for a specific SPN where a forest (realm) feels responsible for.
>
> Let me go in detail with a realworld example:
>
> Two forests (realms): AD001.COMPANY.NET and COMPANY.NET whereas the latter has 20
> subrealms, e.g., OLD4.COMPANY.NET.
> Client account: [hidden email]
> Target server is hostabc.ad001.company.net, but also has the A record
> app.workspace.company.com, and of course the SPN HTTP/app.workspace.company.com.
>
> Now both forest are set to be responsible for DNS namespace company.com.
> So when [hidden email] issues a TGS-REQ to OLD4.COMPANY.NET for
> HTTP/app.workspace.company.com it receives "Server not found in Kerberos database"
> which makes sense here. Using a client principal from AD001.COMPANY.NET works
> flawlessly. So KFSO would traverse AD001.COMPANY.NET too for the OLD1.COMPANY.NET
> client principal on Windows with SSPI.
>
> MIT Kerberos isn't capable to make use of such a logic because there is none. What
> I have done is to define "app.workspace.company.com = AD001.COMPANY.NET" in the
> [domain_realm], but I don't like this because to do this for every single target I
> want to access and on every single server we have in our server room.
>
> Is there a better way to solve this issue?
>

The documentation (https://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html) suggests two possibilities for this issue, if I'm understanding your problem correctly:

* Add "_kerberos.<FQDN>" DNS records mapping a given system to its corresponding realm.  It's a bit painful, but I've had success with it, provided you have "dns_lookup_realm" set to true (yes, it's technically insecure, but is probably acceptable in most environments).
* The host-based service referrals mechanism also seems promising, and you're certainly running a new enough version of Kerberos to accommodate it.  I have not personally used it (yet), but it maintains security whereas the DNS lookup mechanism does not.

> FWIW: We are running MIT Kerberos 1.13.x/1.15.x on FreeBSD, HP-UX and RHEL6.
> Wirshark pcaps are available privately.
>
> Best regards,
>
> Michael
>
> [1] https://technet.microsoft.com/de-de/library/configure-kerberos-forest-search-order-kfso(v=ws.10).aspx
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>


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

RE: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Osipov, Michael
> On Mar 15, 2017, at 8:15 AM, Osipov, Michael <[hidden email]>
> wrote:
> >
> > Hi folks,
> >
> > we are experiencing a problem with an insufficient Kerberos setup on
> Active Directory
> > side which can be solved on Windows-side with Kerberos Forest Search
> Order [1].
> > What Windows basically does is to traverse a list of Kerberos realms to
> obtain a
> > service ticket for a specific SPN where a forest (realm) feels
> responsible for.
> >
> > Let me go in detail with a realworld example:
> >
> > Two forests (realms): AD001.COMPANY.NET and COMPANY.NET whereas the
> latter has 20
> > subrealms, e.g., OLD4.COMPANY.NET.
> > Client account: [hidden email]
> > Target server is hostabc.ad001.company.net, but also has the A record
> > app.workspace.company.com, and of course the SPN
> HTTP/app.workspace.company.com.
> >
> > Now both forest are set to be responsible for DNS namespace company.com.
> > So when [hidden email] issues a TGS-REQ to OLD4.COMPANY.NET
> for
> > HTTP/app.workspace.company.com it receives "Server not found in Kerberos
> database"
> > which makes sense here. Using a client principal from AD001.COMPANY.NET
> works
> > flawlessly. So KFSO would traverse AD001.COMPANY.NET too for the
> OLD1.COMPANY.NET
> > client principal on Windows with SSPI.
> >
> > MIT Kerberos isn't capable to make use of such a logic because there is
> none. What
> > I have done is to define "app.workspace.company.com = AD001.COMPANY.NET"
> in the
> > [domain_realm], but I don't like this because to do this for every
> single target I
> > want to access and on every single server we have in our server room.
> >
> > Is there a better way to solve this issue?
> >
>
> The documentation (https://web.mit.edu/kerberos/krb5-
> latest/doc/admin/realm_config.html) suggests two possibilities for this
> issue, if I'm understanding your problem correctly:
>
> * Add "_kerberos.<FQDN>" DNS records mapping a given system to its
> corresponding realm.  It's a bit painful, but I've had success with it,
> provided you have "dns_lookup_realm" set to true (yes, it's technically
> insecure, but is probably acceptable in most environments).
> * The host-based service referrals mechanism also seems promising, and
> you're certainly running a new enough version of Kerberos to accommodate
> it.  I have not personally used it (yet), but it maintains security
> whereas the DNS lookup mechanism does not.

Both aren't an option:

1. TXT records are unknown to Windows are all host to realm maping is
performed by the domain controller by querying the global catalog
2. This applies only if your KDC is MIT Kerberos. All of our KDCs
are Active Directory servers. We use MIT Kerberos for only for clients.

Michael

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

Re: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Greg Hudson
On 03/15/2017 10:56 AM, Osipov, Michael wrote:
>> * The host-based service referrals mechanism also seems promising, and
>> you're certainly running a new enough version of Kerberos to accommodate
>> it.  I have not personally used it (yet), but it maintains security
>> whereas the DNS lookup mechanism does not.

> This applies only if your KDC is MIT Kerberos. All of our KDCs
> are Active Directory servers. We use MIT Kerberos for only for clients.

Referrals were actually implemented first by Microsoft and later by us.
The KDC does have to know when to issue a referral to another realm for
a service principal, and I don't know whether it's possible to configure
that to happen across forests in Active Directory.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Osipov, Michael
> On 03/15/2017 10:56 AM, Osipov, Michael wrote:
> >> * The host-based service referrals mechanism also seems promising, and
> >> you're certainly running a new enough version of Kerberos to
> accommodate
> >> it.  I have not personally used it (yet), but it maintains security
> >> whereas the DNS lookup mechanism does not.
>
> > This applies only if your KDC is MIT Kerberos. All of our KDCs
> > are Active Directory servers. We use MIT Kerberos for only for clients.
>
> Referrals were actually implemented first by Microsoft and later by us.
> The KDC does have to know when to issue a referral to another realm for
> a service principal, and I don't know whether it's possible to configure
> that to happen across forests in Active Directory.

So there is basically no way to tell MIT Kerberos if you home realm is
unable to route the request, it should try other realms, correct?

Michael

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

Re: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Sean Elble
In reply to this post by Osipov, Michael
On Mar 15, 2017, at 10:56 AM, Osipov, Michael <[hidden email]> wrote:
>
> Both aren't an option:
>
> 1. TXT records are unknown to Windows are all host to realm maping is
> performed by the domain controller by querying the global catalog

But you could still add TXT records to your domain controllers (assuming they are your DNS servers for UNIX systems as well), correct?  They'd simply point the clients (your FreeBSD/HP-UX/RHEL 6 boxes) at the correct realm for a given host name (e.g., _kerberos.app.workspace.company.com -> AD001.COMPANY.NET).

If the problem were with Windows clients, I'd certainly concede your point, but if your clients are *NIX boxes running MIT Kerberos, wouldn't this be a legitimate option?

Apologies if I'm misunderstanding the situation.

> 2. This applies only if your KDC is MIT Kerberos. All of our KDCs
> are Active Directory servers. We use MIT Kerberos for only for clients.
>
> Michael
>


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

Re: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Greg Hudson
In reply to this post by Osipov, Michael
On 03/15/2017 11:39 AM, Osipov, Michael wrote:
> So there is basically no way to tell MIT Kerberos if you home realm is
> unable to route the request, it should try other realms, correct?

No; we have a fallback realm mechanism in the TGS client code, but it
only tries one realm (determined by TXT records or DNS heuristics) and
you can't configure a list.

We haven't implemented a TGS realm search path because:

1. It's not completely secure, in that an attacker can forge error
messages to make the client walk the list past the ideal destination for
a given service.  FAST TGS was supposed to fix this, but for various
reasons it doesn't.

2. The TGS client code is already really complicated, and we're
reluctant to add more complexity to code that is hard to understand as
it is.

3. There are some caching concerns, which if left unaddressed would lead
to a lot of repeated TGS requests to the earlier realms.

That said, I'm told Heimdal recently added support for a feature like
this, so if Microsoft does as well, that makes us the odd one out, and
we should perhaps reconsider.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Osipov, Michael
In reply to this post by Sean Elble
> On Mar 15, 2017, at 10:56 AM, Osipov, Michael <[hidden email]>
> wrote:
> >
> > Both aren't an option:
> >
> > 1. TXT records are unknown to Windows are all host to realm maping is
> > performed by the domain controller by querying the global catalog
>
> But you could still add TXT records to your domain controllers (assuming
> they are your DNS servers for UNIX systems as well), correct?  They'd
> simply point the clients (your FreeBSD/HP-UX/RHEL 6 boxes) at the correct
> realm for a given host name (e.g., _kerberos.app.workspace.company.com ->
> AD001.COMPANY.NET).
>
> If the problem were with Windows clients, I'd certainly concede your
> point, but if your clients are *NIX boxes running MIT Kerberos, wouldn't
> this be a legitimate option?

We are in full control of DNS, but I cannot make any changes. I am a peasant
in a 300 000-people-company. Everything is administered centrally.

Even if I could, TXT has no clear notion on Windows/Active Directory.

 
> Apologies if I'm misunderstanding the situation.

No need to apologize!
 
Michael

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

RE: Mimicking AD's Kerberos Forest Search Order (KFSO) with MIT Kerberos

Osipov, Michael
In reply to this post by Greg Hudson
> On 03/15/2017 11:39 AM, Osipov, Michael wrote:
> > So there is basically no way to tell MIT Kerberos if you home realm is
> > unable to route the request, it should try other realms, correct?
>
> No; we have a fallback realm mechanism in the TGS client code, but it
> only tries one realm (determined by TXT records or DNS heuristics) and
> you can't configure a list.
>
> We haven't implemented a TGS realm search path because:
>
> 1. It's not completely secure, in that an attacker can forge error
> messages to make the client walk the list past the ideal destination for
> a given service.  FAST TGS was supposed to fix this, but for various
> reasons it doesn't.

At which point would attacker be able to forge a message?
DNS updates here are via GSS-TSIG only. Krb5.conf can be changed by root
only. I would expect this search list reside in krb5.conf.Nein

> 2. The TGS client code is already really complicated, and we're
> reluctant to add more complexity to code that is hard to understand as
> it is.
>
> 3. There are some caching concerns, which if left unaddressed would lead
> to a lot of repeated TGS requests to the earlier realms.

Acknowledged.

> That said, I'm told Heimdal recently added support for a feature like
> this, so if Microsoft does as well, that makes us the odd one out, and
> we should perhaps reconsider.

I checked Heimdal's git log from today back to 2015, haven't found anything.
Can you name the change in particular?

If you are up to reconsidering, I asked a related topic almost a year ago [1]
Without any answer. The search order issue only applies to SPNs with two
components -- namely without a realm indication.

Can you create a ticket for this feature in your bug tracker?

If you reach some code state, I can test anytime from master. I have several
huge forests at hand. Just ping me privately.

Best regards,

Michael

[1] https://www.mail-archive.com/kerberos@.../msg21765.html

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Loading...