Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Matthieu Patou]

On 14/11/2011 02:17, Jeff Layton wrote:

> We've had a request recently to allow cifs.upcall to use AD-style
> service principals. While trying to nail down what they need, I asked
> Simo his opinion on how best to pick a service principal for a given
> hostname. His suggestion was:
>
> 	INPUT: fooo
> 	TRY in order:
>    		FOOO$@REALM
> 		cifs/fooo.<guessed domain ?>@REALM
>    		host/fooo.<guessed domain ?>@REALM
>
> 	INPUT: bar.example.com
> 	TRY in order:
> 		cifs/bar.example.com@REALM
> 		BAR$@REALM
> 		host/bar.example.com@REALM
>
> This patchset attempts to embody that logic.
>
> Suggestions welcome. Those reviewing it, please pay particular attention
> to the scheme for guessing a domain name. I want to make certain that
> we're not opening up any security holes with that scheme.

Jeff, you have to pay attention to DFS volumes.
IE. if I want to mount //mydomain.corp/sysvol you will never get a 
ticket for cifs/mydomain.corp@REALM instead you need to locate with 
trans2 calls (for smb1, I don't remember the name for smb2) the domain 
controlers (DC) that could provide you the share.
For sysvol it's still quite simple but you can have other DFS volume 
that are not stored on DC, would be great to have DFS awareness in the 
cifs client.

Matthieu

-- 
Matthieu Patou
Samba Team
http://samba.org

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Jeff Layton]

On Tue, 15 Nov 2011 12:18:52 +0100
Matthieu Patou <mat-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:

> On 14/11/2011 02:17, Jeff Layton wrote:
> 
> > We've had a request recently to allow cifs.upcall to use AD-style
> > service principals. While trying to nail down what they need, I asked
> > Simo his opinion on how best to pick a service principal for a given
> > hostname. His suggestion was:
> >
> > 	INPUT: fooo
> > 	TRY in order:
> >    		FOOO$@REALM
> > 		cifs/fooo.<guessed domain ?>@REALM
> >    		host/fooo.<guessed domain ?>@REALM
> >
> > 	INPUT: bar.example.com
> > 	TRY in order:
> > 		cifs/bar.example.com@REALM
> > 		BAR$@REALM
> > 		host/bar.example.com@REALM
> >
> > This patchset attempts to embody that logic.
> >
> > Suggestions welcome. Those reviewing it, please pay particular attention
> > to the scheme for guessing a domain name. I want to make certain that
> > we're not opening up any security holes with that scheme.
> 
> Jeff, you have to pay attention to DFS volumes.
> IE. if I want to mount //mydomain.corp/sysvol you will never get a 
> ticket for cifs/mydomain.corp@REALM instead you need to locate with 
> trans2 calls (for smb1, I don't remember the name for smb2) the domain 
> controlers (DC) that could provide you the share.
> For sysvol it's still quite simple but you can have other DFS volume 
> that are not stored on DC, would be great to have DFS awareness in the 
> cifs client.
> 

Woah, that's a whole different problem altogether.

Currently the DFS code relies on being able to resolve the hostname
portion of the UNC in a DFS referral using getaddrinfo in an upcall. If
you want to do anything more elaborate, then that's really a separate
project.

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

[PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Jeff Layton]

We've had a request recently to allow cifs.upcall to use AD-style
service principals. While trying to nail down what they need, I asked
Simo his opinion on how best to pick a service principal for a given
hostname. His suggestion was:

	INPUT: fooo
	TRY in order:
  		FOOO$@REALM
		cifs/fooo.<guessed domain ?>@REALM
  		host/fooo.<guessed domain ?>@REALM

	INPUT: bar.example.com
	TRY in order:
		cifs/bar.example.com@REALM
		BAR$@REALM
		host/bar.example.com@REALM

This patchset attempts to embody that logic.

Suggestions welcome. Those reviewing it, please pay particular attention
to the scheme for guessing a domain name. I want to make certain that
we're not opening up any security holes with that scheme.

Jeff Layton (3):
  cifs.upcall: move to an on-stack princ buffer
  cifs.upcall: move to Simo's suggested algorithm for picking a
    principal
  cifs.upcall: try and guess the domain name on unqualified names

 cifs.upcall.c |  143 ++++++++++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 117 insertions(+), 26 deletions(-)

-- 
1.7.6.4

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Andrew Bartlett]

On Sun, 2011-11-13 at 20:17 -0500, Jeff Layton wrote:
> We've had a request recently to allow cifs.upcall to use AD-style
> service principals. While trying to nail down what they need, I asked
> Simo his opinion on how best to pick a service principal for a given
> hostname. His suggestion was:
> 
> 	INPUT: fooo
> 	TRY in order:
>   		FOOO$@REALM
> 		cifs/fooo.<guessed domain ?>@REALM
>   		host/fooo.<guessed domain ?>@REALM
> 
> 	INPUT: bar.example.com
> 	TRY in order:
> 		cifs/bar.example.com@REALM
> 		BAR$@REALM
> 		host/bar.example.com@REALM
> 
> This patchset attempts to embody that logic.
> 
> Suggestions welcome. Those reviewing it, please pay particular attention
> to the scheme for guessing a domain name. I want to make certain that
> we're not opening up any security holes with that scheme.

Perhaps I'm missing some background, but this looks wrong to me, at
least for the pure AD case.  

First, in AD cifs/ is an alias of host/, so looking for both will not
help.  Secondly, looking for bar$ is an outright guess, as there is no
reliable mapping between a long name in DNS and the short
samAccountName.

If we map wrongly, we might luck out and get a KDC error indicating no
such host, or we might fail at session setup time, with logon failure. 

What is wrong with simply requesting a principal of cifs/INPUT@REALM?
In AD, the KDC does all the canonicalisation work (perhaps I should have
clarified this in the previous thread).

Thanks,

Andrew Bartlett



-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[simo]

On Mon, 2011-11-14 at 13:28 +1100, Andrew Bartlett wrote: 
> On Sun, 2011-11-13 at 20:17 -0500, Jeff Layton wrote:
> > We've had a request recently to allow cifs.upcall to use AD-style
> > service principals. While trying to nail down what they need, I asked
> > Simo his opinion on how best to pick a service principal for a given
> > hostname. His suggestion was:
> > 
> > 	INPUT: fooo
> > 	TRY in order:
> >   		FOOO$@REALM
> > 		cifs/fooo.<guessed domain ?>@REALM
> >   		host/fooo.<guessed domain ?>@REALM
> > 
> > 	INPUT: bar.example.com
> > 	TRY in order:
> > 		cifs/bar.example.com@REALM
> > 		BAR$@REALM
> > 		host/bar.example.com@REALM
> > 
> > This patchset attempts to embody that logic.
> > 
> > Suggestions welcome. Those reviewing it, please pay particular attention
> > to the scheme for guessing a domain name. I want to make certain that
> > we're not opening up any security holes with that scheme.
> 
> Perhaps I'm missing some background, but this looks wrong to me, at
> least for the pure AD case.  
> 
> First, in AD cifs/ is an alias of host/, so looking for both will not
> help.  Secondly, looking for bar$ is an outright guess, as there is no
> reliable mapping between a long name in DNS and the short
> samAccountName.
> 
> If we map wrongly, we might luck out and get a KDC error indicating no
> such host, or we might fail at session setup time, with logon failure. 
> 
> What is wrong with simply requesting a principal of cifs/INPUT@REALM?
> In AD, the KDC does all the canonicalisation work (perhaps I should have
> clarified this in the previous thread).

What is wrong is that it works only with AD. The above heuristics should
allow more flexibility against both AD and samba servers configured to
use other KDCs.

Simo.


-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Jeff Layton]

On Sun, 13 Nov 2011 22:12:31 -0500
simo <idra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:

> On Mon, 2011-11-14 at 13:28 +1100, Andrew Bartlett wrote: 
> > On Sun, 2011-11-13 at 20:17 -0500, Jeff Layton wrote:
> > > We've had a request recently to allow cifs.upcall to use AD-style
> > > service principals. While trying to nail down what they need, I asked
> > > Simo his opinion on how best to pick a service principal for a given
> > > hostname. His suggestion was:
> > > 
> > > 	INPUT: fooo
> > > 	TRY in order:
> > >   		FOOO$@REALM
> > > 		cifs/fooo.<guessed domain ?>@REALM
> > >   		host/fooo.<guessed domain ?>@REALM
> > > 
> > > 	INPUT: bar.example.com
> > > 	TRY in order:
> > > 		cifs/bar.example.com@REALM
> > > 		BAR$@REALM
> > > 		host/bar.example.com@REALM
> > > 
> > > This patchset attempts to embody that logic.
> > > 
> > > Suggestions welcome. Those reviewing it, please pay particular attention
> > > to the scheme for guessing a domain name. I want to make certain that
> > > we're not opening up any security holes with that scheme.
> > 
> > Perhaps I'm missing some background, but this looks wrong to me, at
> > least for the pure AD case.  
> > 
> > First, in AD cifs/ is an alias of host/, so looking for both will not
> > help.  Secondly, looking for bar$ is an outright guess, as there is no
> > reliable mapping between a long name in DNS and the short
> > samAccountName.
> > 
> > If we map wrongly, we might luck out and get a KDC error indicating no
> > such host, or we might fail at session setup time, with logon failure. 
> > 
> > What is wrong with simply requesting a principal of cifs/INPUT@REALM?
> > In AD, the KDC does all the canonicalisation work (perhaps I should have
> > clarified this in the previous thread).
> 
> What is wrong is that it works only with AD. The above heuristics should
> allow more flexibility against both AD and samba servers configured to
> use other KDCs.
> 

The above scheme isn't perfect, but in many cases it will happen to
work. It's true that there's no reliable mapping between DNS and
samAccountName, but in a lot of cases the samAccountName *is* the
capitalized host portion of the DNS name. Does it hurt anything to
attempt to get a ticket with that name if "cifs/fqdn" fails?

Over the years, we've seen a lot of confused users on the list who are
not sure what name they need to put in the host portion of the UNC to
get their krb5 mount to work. This scheme seems like it'll make that a
bit more forgiving.

If the wrong guesses just end up slowing down the upcall, then I'm ok
with that. If they potentially open a security hole then that's another
matter entirely. That's my main question here -- are we opening up any
vulnerabilities with this scheme?

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Andrew Bartlett]

On Mon, 2011-11-14 at 09:44 -0500, Jeff Layton wrote:

> The above scheme isn't perfect, but in many cases it will happen to
> work. It's true that there's no reliable mapping between DNS and
> samAccountName, but in a lot of cases the samAccountName *is* the
> capitalized host portion of the DNS name. Does it hurt anything to
> attempt to get a ticket with that name if "cifs/fqdn" fails?

We should never ask for a machine$ name.  It is always the wrong thing
to do, because it will only exist on AD servers, which already do the
mapping between cifs/foo and foo$ internally.  

We should also not map between cifs/ and host/ - cifs/ is a separate
service, just as nfs/ and http/ are. 

> Over the years, we've seen a lot of confused users on the list who are
> not sure what name they need to put in the host portion of the UNC to
> get their krb5 mount to work. This scheme seems like it'll make that a
> bit more forgiving.

I certainly understand the need to make krb5 more forgiving, and
certainly if the KDC indicates that cifs/foo does not exist, then
guessing the DNS domain and asking for cifs/foo.<guessed domain> is
reasonable.  

> If the wrong guesses just end up slowing down the upcall, then I'm ok
> with that. If they potentially open a security hole then that's another
> matter entirely. That's my main question here -- are we opening up any
> vulnerabilities with this scheme?

Each time you second-guess the name, you open up a small security hole,
because you potentially allow a connection that was to be to a trusted
host to be impersonated by less trusted member of the same kerberos
realm.  For that reason, any client-side canonicalisation should be
strictly limited.  

Furthermore, you may do more than just slow down the upcall - if you
connect to the right server with the wrong ticket (because you guessed
wrong - cifs vs host etc), the only way to find out is if the server
gives you a LOGON_FAILURE error, and I think this will be even harder to
debug. 

I do want kerberos to be easier to use, and to 'just work' more often.
I care passionately that Kerberos should be both secure and 'just work'
- falling back to NTLM is an even worse fate.  

I just want to ensure we do not become the source of new expected
behaviour patterns for non-AD domains (such as looking up foo$ or
host/foo for cifs shares), as once we start, it will be very hard to
undo. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[simo]

On Tue, 2011-11-15 at 09:45 +1100, Andrew Bartlett wrote: 
> On Mon, 2011-11-14 at 09:44 -0500, Jeff Layton wrote:
> 
> > The above scheme isn't perfect, but in many cases it will happen to
> > work. It's true that there's no reliable mapping between DNS and
> > samAccountName, but in a lot of cases the samAccountName *is* the
> > capitalized host portion of the DNS name. Does it hurt anything to
> > attempt to get a ticket with that name if "cifs/fqdn" fails?
> 
> We should never ask for a machine$ name.  It is always the wrong thing
> to do, because it will only exist on AD servers, which already do the
> mapping between cifs/foo and foo$ internally.  

You are contradicting yourself here.
First you say foo may not be the short name then you advocate for not
using foo$. But asking for foo$ comes handly exactly when the short name
is not the same as the fqdn truncated, as a use may pass on the command
line and that's why it was added.

> We should also not map between cifs/ and host/ - cifs/ is a separate
> service, just as nfs/ and http/ are. 

And yet it is possible to have cifs servers work when using the host/
ticket. Trying and failing is not a big deal.

> > Over the years, we've seen a lot of confused users on the list who are
> > not sure what name they need to put in the host portion of the UNC to
> > get their krb5 mount to work. This scheme seems like it'll make that a
> > bit more forgiving.
> 
> I certainly understand the need to make krb5 more forgiving, and
> certainly if the KDC indicates that cifs/foo does not exist, then
> guessing the DNS domain and asking for cifs/foo.<guessed domain> is
> reasonable.  
> 
> > If the wrong guesses just end up slowing down the upcall, then I'm ok
> > with that. If they potentially open a security hole then that's another
> > matter entirely. That's my main question here -- are we opening up any
> > vulnerabilities with this scheme?
> 
> Each time you second-guess the name, you open up a small security hole,
> because you potentially allow a connection that was to be to a trusted
> host to be impersonated by less trusted member of the same kerberos
> realm.  For that reason, any client-side canonicalisation should be
> strictly limited.  

While this is somewhat true, it is not always true. Sometimes
convenience is more important. If a user wants to be sure to get to the
right server he only has to provide the full fqdn, and the right match
will be done. The only case when the wrong case may happen is when the
user only provides the short name. But there isn't much you can do
there, unless you want to flatly refuse to work if users do not give a
fqdn.

> Furthermore, you may do more than just slow down the upcall - if you
> connect to the right server with the wrong ticket (because you guessed
> wrong - cifs vs host etc), the only way to find out is if the server
> gives you a LOGON_FAILURE error, and I think this will be even harder to
> debug. 

If cifs/ failed and later host/ also fails then there isn't much you can
do anyway. You'd be right to complain if we tried host/ first. We are
not doing that.

> I do want kerberos to be easier to use, and to 'just work' more often.
> I care passionately that Kerberos should be both secure and 'just work'
> - falling back to NTLM is an even worse fate.  
> 
> I just want to ensure we do not become the source of new expected
> behaviour patterns for non-AD domains (such as looking up foo$ or
> host/foo for cifs shares), as once we start, it will be very hard to
> undo. 

hard in what sense ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Andrew Bartlett]

On Mon, 2011-11-14 at 18:04 -0500, simo wrote:
> On Tue, 2011-11-15 at 09:45 +1100, Andrew Bartlett wrote: 
> > On Mon, 2011-11-14 at 09:44 -0500, Jeff Layton wrote:
> > 
> > > The above scheme isn't perfect, but in many cases it will happen to
> > > work. It's true that there's no reliable mapping between DNS and
> > > samAccountName, but in a lot of cases the samAccountName *is* the
> > > capitalized host portion of the DNS name. Does it hurt anything to
> > > attempt to get a ticket with that name if "cifs/fqdn" fails?
> > 
> > We should never ask for a machine$ name.  It is always the wrong thing
> > to do, because it will only exist on AD servers, which already do the
> > mapping between cifs/foo and foo$ internally.  
> 
> You are contradicting yourself here.
> First you say foo may not be the short name then you advocate for not
> using foo$. But asking for foo$ comes handly exactly when the short name
> is not the same as the fqdn truncated, as a use may pass on the command
> line and that's why it was added.

You should never truncate a FQDN.  If the user connects with a FQDN we
should always use cifs/FQDN as the only name that is attempted.  

> > We should also not map between cifs/ and host/ - cifs/ is a separate
> > service, just as nfs/ and http/ are. 
> 
> And yet it is possible to have cifs servers work when using the host/
> ticket. Trying and failing is not a big deal.

I disagree, and just because some servers accept the host/ principal
does not mean we should use it.  Kerberos specifically defines service
types, and we should use them as intended. 

> > > Over the years, we've seen a lot of confused users on the list who are
> > > not sure what name they need to put in the host portion of the UNC to
> > > get their krb5 mount to work. This scheme seems like it'll make that a
> > > bit more forgiving.
> > 
> > I certainly understand the need to make krb5 more forgiving, and
> > certainly if the KDC indicates that cifs/foo does not exist, then
> > guessing the DNS domain and asking for cifs/foo.<guessed domain> is
> > reasonable.  
> > 
> > > If the wrong guesses just end up slowing down the upcall, then I'm ok
> > > with that. If they potentially open a security hole then that's another
> > > matter entirely. That's my main question here -- are we opening up any
> > > vulnerabilities with this scheme?
> > 
> > Each time you second-guess the name, you open up a small security hole,
> > because you potentially allow a connection that was to be to a trusted
> > host to be impersonated by less trusted member of the same kerberos
> > realm.  For that reason, any client-side canonicalisation should be
> > strictly limited.  
> 
> While this is somewhat true, it is not always true. Sometimes
> convenience is more important. If a user wants to be sure to get to the
> right server he only has to provide the full fqdn, and the right match
> will be done. The only case when the wrong case may happen is when the
> user only provides the short name. But there isn't much you can do
> there, unless you want to flatly refuse to work if users do not give a
> fqdn.

Allowing the local domain to be appended seems quite reasonable, after
cifs/ is not found.  We could also follow the policy of the local
kerberos library for other applications.  

> > Furthermore, you may do more than just slow down the upcall - if you
> > connect to the right server with the wrong ticket (because you guessed
> > wrong - cifs vs host etc), the only way to find out is if the server
> > gives you a LOGON_FAILURE error, and I think this will be even harder to
> > debug. 
> 
> If cifs/ failed and later host/ also fails then there isn't much you can
> do anyway. You'd be right to complain if we tried host/ first. We are
> not doing that.

I still think we should never use host/.

> > I do want kerberos to be easier to use, and to 'just work' more often.
> > I care passionately that Kerberos should be both secure and 'just work'
> > - falling back to NTLM is an even worse fate.  
> > 
> > I just want to ensure we do not become the source of new expected
> > behaviour patterns for non-AD domains (such as looking up foo$ or
> > host/foo for cifs shares), as once we start, it will be very hard to
> > undo. 
> 
> hard in what sense ?

Patterns of server and administrator behaviour are in part set by
patterns of client behaviour.  Therefore, if Samba starts asking for foo
$ or host/foo tickets, then administrators attempting to debug failures
will start creating such principals in their non-AD KDCs, and soon it
becomes internet folklore and 'best practice'.  Once this starts, it is
very hard to undo, which is why I strongly advocate for doing the exact
minimum to make this work, and no more. 

No other cifs client asks for foo$ or host/, and Samba even stopped
doing so indirectly with 3.5.8 (using the server-supplied principal).  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Jeff Layton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 15 Nov 2011 12:10:08 +1100
Andrew Bartlett <abartlet@samba.org> wrote:

> On Mon, 2011-11-14 at 18:04 -0500, simo wrote:
> > On Tue, 2011-11-15 at 09:45 +1100, Andrew Bartlett wrote: 
> > > On Mon, 2011-11-14 at 09:44 -0500, Jeff Layton wrote:
> > > 
> > > > The above scheme isn't perfect, but in many cases it will happen to
> > > > work. It's true that there's no reliable mapping between DNS and
> > > > samAccountName, but in a lot of cases the samAccountName *is* the
> > > > capitalized host portion of the DNS name. Does it hurt anything to
> > > > attempt to get a ticket with that name if "cifs/fqdn" fails?
> > > 
> > > We should never ask for a machine$ name.  It is always the wrong thing
> > > to do, because it will only exist on AD servers, which already do the
> > > mapping between cifs/foo and foo$ internally.  
> > 
> > You are contradicting yourself here.
> > First you say foo may not be the short name then you advocate for not
> > using foo$. But asking for foo$ comes handly exactly when the short name
> > is not the same as the fqdn truncated, as a use may pass on the command
> > line and that's why it was added.
> 
> You should never truncate a FQDN.  If the user connects with a FQDN we
> should always use cifs/FQDN as the only name that is attempted.  
> 
> > > We should also not map between cifs/ and host/ - cifs/ is a separate
> > > service, just as nfs/ and http/ are. 
> > 
> > And yet it is possible to have cifs servers work when using the host/
> > ticket. Trying and failing is not a big deal.
> 
> I disagree, and just because some servers accept the host/ principal
> does not mean we should use it.  Kerberos specifically defines service
> types, and we should use them as intended. 
> 
> > > > Over the years, we've seen a lot of confused users on the list who are
> > > > not sure what name they need to put in the host portion of the UNC to
> > > > get their krb5 mount to work. This scheme seems like it'll make that a
> > > > bit more forgiving.
> > > 
> > > I certainly understand the need to make krb5 more forgiving, and
> > > certainly if the KDC indicates that cifs/foo does not exist, then
> > > guessing the DNS domain and asking for cifs/foo.<guessed domain> is
> > > reasonable.  
> > > 
> > > > If the wrong guesses just end up slowing down the upcall, then I'm ok
> > > > with that. If they potentially open a security hole then that's another
> > > > matter entirely. That's my main question here -- are we opening up any
> > > > vulnerabilities with this scheme?
> > > 
> > > Each time you second-guess the name, you open up a small security hole,
> > > because you potentially allow a connection that was to be to a trusted
> > > host to be impersonated by less trusted member of the same kerberos
> > > realm.  For that reason, any client-side canonicalisation should be
> > > strictly limited.  
> > 
> > While this is somewhat true, it is not always true. Sometimes
> > convenience is more important. If a user wants to be sure to get to the
> > right server he only has to provide the full fqdn, and the right match
> > will be done. The only case when the wrong case may happen is when the
> > user only provides the short name. But there isn't much you can do
> > there, unless you want to flatly refuse to work if users do not give a
> > fqdn.
> 
> Allowing the local domain to be appended seems quite reasonable, after
> cifs/ is not found.  We could also follow the policy of the local
> kerberos library for other applications.  
> 
> > > Furthermore, you may do more than just slow down the upcall - if you
> > > connect to the right server with the wrong ticket (because you guessed
> > > wrong - cifs vs host etc), the only way to find out is if the server
> > > gives you a LOGON_FAILURE error, and I think this will be even harder to
> > > debug. 
> > 
> > If cifs/ failed and later host/ also fails then there isn't much you can
> > do anyway. You'd be right to complain if we tried host/ first. We are
> > not doing that.
> 
> I still think we should never use host/.
> 
> > > I do want kerberos to be easier to use, and to 'just work' more often.
> > > I care passionately that Kerberos should be both secure and 'just work'
> > > - falling back to NTLM is an even worse fate.  
> > > 
> > > I just want to ensure we do not become the source of new expected
> > > behaviour patterns for non-AD domains (such as looking up foo$ or
> > > host/foo for cifs shares), as once we start, it will be very hard to
> > > undo. 
> > 
> > hard in what sense ?
> 
> Patterns of server and administrator behaviour are in part set by
> patterns of client behaviour.  Therefore, if Samba starts asking for foo
> $ or host/foo tickets, then administrators attempting to debug failures
> will start creating such principals in their non-AD KDCs, and soon it
> becomes internet folklore and 'best practice'.  Once this starts, it is
> very hard to undo, which is why I strongly advocate for doing the exact
> minimum to make this work, and no more. 
> 
> No other cifs client asks for foo$ or host/, and Samba even stopped
> doing so indirectly with 3.5.8 (using the server-supplied principal).  
> 

Ok, based on the comments so far, how does this sound for a potential
scheme:

	INPUT: foo
	TRY:
	    FOO$
	    cifs/foo.[guessed domain]

	INPUT: foo.example.com
	TRY:
	    cifs/foo.example.com

To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
then guess a domain name, append the value to the hostname, and prepend
it with "cifs/".

If we get something that looks like a FQDN, then just prepend it with
"cifs/" and then give up if that doesn't work.

Sound about right?
- -- 
Jeff Layton <jlayton@samba.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBAgAGBQJOwnPvAAoJEAAOaEEZVoIV3MkP/jIf1sUkP3WmWa/8TI3jqxvH
pAwahEGP0QM56rRKHkcnwIBClwwZ+fO8VxF4gXs42Hqqe1DozsKVcWp2N93VW7X7
o+Z221Z+HEO2WpXGl7NxaJcno0+/lXDUTL+Ui6eEsS55jv3ieHk8tehNv6MFJc2D
2bmdLyNWIOBFDlxIHIK1ChjCSE5j7DDgtOYI/7bf4wHKYhtbFNYvOXyPOSFDl5eT
9cqZMu8hD5vuNDNdAfHpe0pA7j+qRkXuOa61ElKL8fTUOz67iOS0jwg4gg8xQe8o
ipWW3M5rxsGoAnUagA/acwoqcymvpDoDwtDYKBzdwZUbN/+9fmMIC7AMtyad8n59
wENO/xlXnO6TUizWdNSrOLZQ3sZekkn/hzJkOP/iWnrCDWjsWUmRFxq4FZ7E6SGl
GP9ABiNwLf/f8u43I4ojqRVDGOcj7dL8JxEtAzVJB9uKUg6vbCw3zJv1oEeXl/wl
S9vmzy0D2TnAMImnGUR/Vm1XBBgQSOVkHl/rUIO2R2tefiel+f7FSQphVBk/NTvj
A2TpSk5otm5RwvEpBfPJ2QsbaNpkDJAqost7ScABOGqWqKAw3Xvv5VrLXo9vx+uO
OJ4yIq5HHA0e0aBGzXXw27+7wUDW6PqZMZA7gGtaSNMbcRiMqKNowm6F1r5fzCJ3
5u6wb7Z/ZRU8W69thBAf
=pkM5
-----END PGP SIGNATURE-----

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Andrew Bartlett]

On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote:

> Ok, based on the comments so far, how does this sound for a potential
> scheme:
> 
> 	INPUT: foo
> 	TRY:
> 	    FOO$
> 	    cifs/foo.[guessed domain]
> 
>	INPUT: foo.example.com
> 	TRY:
> 	    cifs/foo.example.com
> 
> To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
> then guess a domain name, append the value to the hostname, and prepend
> it with "cifs/".

No, we should never use FOO$ (this is AD only, and equivalent to
cifs/foo), so we should instead simply do:

INPUT: foo
TRY:
    cifs/foo
    cifs/foo.[guessed domain]

INPUT: foo.example.com
TRY:
    cifs/foo.example.com

I would prefer that the kerberos client library actually did this (as
then it would 'just work' for all other kerberos applications), but
sadly the behaviour here is not always what you expect, and can use
reverse DNS (which is an even worse fate).  See the rdns option in
krb5.conf (which I typically turn off). 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[simo]

On Wed, 2011-11-16 at 08:37 +1100, Andrew Bartlett wrote: 
> On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote:
> 
> > Ok, based on the comments so far, how does this sound for a potential
> > scheme:
> > 
> > 	INPUT: foo
> > 	TRY:
> > 	    FOO$
> > 	    cifs/foo.[guessed domain]
> > 
> >	INPUT: foo.example.com
> > 	TRY:
> > 	    cifs/foo.example.com
> > 
> > To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
> > then guess a domain name, append the value to the hostname, and prepend
> > it with "cifs/".
> 
> No, we should never use FOO$ (this is AD only, and equivalent to
> cifs/foo), so we should instead simply do:
> 
> INPUT: foo
> TRY:
>     cifs/foo

This ^^^^ is also AD-only, so what's the point of objecting to one or
another ?
At least when you see FOO$@REALM, admins know it is an AD only thing.

> cifs/foo.[guessed domain]
> 
> INPUT: foo.example.com
> TRY:
>     cifs/foo.example.com
> 
> I would prefer that the kerberos client library actually did this (as
> then it would 'just work' for all other kerberos applications), but
> sadly the behaviour here is not always what you expect, and can use
> reverse DNS (which is an even worse fate).  See the rdns option in
> krb5.conf (which I typically turn off). 
> 
> Andrew Bartlett


-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Andrew Bartlett]

On Wed, 2011-11-16 at 11:08 -0500, simo wrote:
> On Wed, 2011-11-16 at 08:37 +1100, Andrew Bartlett wrote: 
> > On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote:
> > 
> > > Ok, based on the comments so far, how does this sound for a potential
> > > scheme:
> > > 
> > > 	INPUT: foo
> > > 	TRY:
> > > 	    FOO$
> > > 	    cifs/foo.[guessed domain]
> > > 
> > >	INPUT: foo.example.com
> > > 	TRY:
> > > 	    cifs/foo.example.com
> > > 
> > > To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
> > > then guess a domain name, append the value to the hostname, and prepend
> > > it with "cifs/".
> > 
> > No, we should never use FOO$ (this is AD only, and equivalent to
> > cifs/foo), so we should instead simply do:
> > 
> > INPUT: foo
> > TRY:
> >     cifs/foo
> 
> This ^^^^ is also AD-only, so what's the point of objecting to one or
> another ?
> At least when you see FOO$@REALM, admins know it is an AD only thing.

The reason that we should not translate between foo and foo$ on the
client side is that a server may have multiple service principal names.
A host with multiple names will have only one machine account in AD, and
we have no way to know that this particular name is that of the machine
account.

Also, while requests for cifs/foo will cause a lookup of host/foo and
foo$ on the server side, this is a server-side fallback, not an absolute
rule.  If an account has the more specific form as a
servicePrincipalName, then implicit mappings are not needed.  We cannot
on a client make assumptions about how the administrator has configured
their domain.

Finally, cifs/foo is a perfectly valid and reasonable kerberos service
principal name, and the name that other cifs clients such as Samba 3.6,
and Windows will use, and so we should ensure constancy with those
clients to reduce the administrator burden in the non-AD case. 

Indeed, it is this final reason why this process is futile.  The correct
fix is to ensure that the non-AD KDC has principal entries for each
aliases (cifs/foo and cifs/foo.domain) by which the server can be
resolved. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Jeff Layton]

On Thu, 17 Nov 2011 21:16:40 +1100
Andrew Bartlett <abartlet@samba.org> wrote:

> On Wed, 2011-11-16 at 11:08 -0500, simo wrote:
> > On Wed, 2011-11-16 at 08:37 +1100, Andrew Bartlett wrote: 
> > > On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote:
> > > 
> > > > Ok, based on the comments so far, how does this sound for a potential
> > > > scheme:
> > > > 
> > > > 	INPUT: foo
> > > > 	TRY:
> > > > 	    FOO$
> > > > 	    cifs/foo.[guessed domain]
> > > > 
> > > >	INPUT: foo.example.com
> > > > 	TRY:
> > > > 	    cifs/foo.example.com
> > > > 
> > > > To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
> > > > then guess a domain name, append the value to the hostname, and prepend
> > > > it with "cifs/".
> > > 
> > > No, we should never use FOO$ (this is AD only, and equivalent to
> > > cifs/foo), so we should instead simply do:
> > > 
> > > INPUT: foo
> > > TRY:
> > >     cifs/foo
> > 
> > This ^^^^ is also AD-only, so what's the point of objecting to one or
> > another ?
> > At least when you see FOO$@REALM, admins know it is an AD only thing.
> 
> The reason that we should not translate between foo and foo$ on the
> client side is that a server may have multiple service principal names.
> A host with multiple names will have only one machine account in AD, and
> we have no way to know that this particular name is that of the machine
> account.
> 
> Also, while requests for cifs/foo will cause a lookup of host/foo and
> foo$ on the server side, this is a server-side fallback, not an absolute
> rule.  If an account has the more specific form as a
> servicePrincipalName, then implicit mappings are not needed.  We cannot
> on a client make assumptions about how the administrator has configured
> their domain.
> 
> Finally, cifs/foo is a perfectly valid and reasonable kerberos service
> principal name, and the name that other cifs clients such as Samba 3.6,
> and Windows will use, and so we should ensure constancy with those
> clients to reduce the administrator burden in the non-AD case. 
> 
> Indeed, it is this final reason why this process is futile.  The correct
> fix is to ensure that the non-AD KDC has principal entries for each
> aliases (cifs/foo and cifs/foo.domain) by which the server can be
> resolved. 
> 

Ok, to summarize:

Andrew says that there's no reason to ever try to get anything but
a "cifs/" principal. In the case of an unqualified hostname, we should
try to get a "cifs/" principal with the given hostname first, and then
append a guessed domain name if that fails.

Simo are you in agreement here? Or can you think of any cases where we
should try to do anything different?

Another question:

Most KDC's are case-sensitive, but DNS is generally case-insensitive.
Should we attempt to convert the hostname to all-lowercase when
constructing the principal name to use? I don't think we want to
encourage admins to put in principals for all possible combinations of
upper and lower case...

-- 
Jeff Layton <jlayton@samba.org>

Re: [PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Andrew Bartlett]

On Thu, 2011-11-17 at 08:12 -0500, Jeff Layton wrote:
> On Thu, 17 Nov 2011 21:16:40 +1100
> Andrew Bartlett <abartlet-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> 
> > On Wed, 2011-11-16 at 11:08 -0500, simo wrote:
> > > On Wed, 2011-11-16 at 08:37 +1100, Andrew Bartlett wrote: 
> > > > On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote:
> > > > 
> > > > > Ok, based on the comments so far, how does this sound for a potential
> > > > > scheme:
> > > > > 
> > > > > 	INPUT: foo
> > > > > 	TRY:
> > > > > 	    FOO$
> > > > > 	    cifs/foo.[guessed domain]
> > > > > 
> > > > >	INPUT: foo.example.com
> > > > > 	TRY:
> > > > > 	    cifs/foo.example.com
> > > > > 
> > > > > To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
> > > > > then guess a domain name, append the value to the hostname, and prepend
> > > > > it with "cifs/".
> > > > 
> > > > No, we should never use FOO$ (this is AD only, and equivalent to
> > > > cifs/foo), so we should instead simply do:
> > > > 
> > > > INPUT: foo
> > > > TRY:
> > > >     cifs/foo
> > > 
> > > This ^^^^ is also AD-only, so what's the point of objecting to one or
> > > another ?
> > > At least when you see FOO$@REALM, admins know it is an AD only thing.
> > 
> > The reason that we should not translate between foo and foo$ on the
> > client side is that a server may have multiple service principal names.
> > A host with multiple names will have only one machine account in AD, and
> > we have no way to know that this particular name is that of the machine
> > account.
> > 
> > Also, while requests for cifs/foo will cause a lookup of host/foo and
> > foo$ on the server side, this is a server-side fallback, not an absolute
> > rule.  If an account has the more specific form as a
> > servicePrincipalName, then implicit mappings are not needed.  We cannot
> > on a client make assumptions about how the administrator has configured
> > their domain.
> > 
> > Finally, cifs/foo is a perfectly valid and reasonable kerberos service
> > principal name, and the name that other cifs clients such as Samba 3.6,
> > and Windows will use, and so we should ensure constancy with those
> > clients to reduce the administrator burden in the non-AD case. 
> > 
> > Indeed, it is this final reason why this process is futile.  The correct
> > fix is to ensure that the non-AD KDC has principal entries for each
> > aliases (cifs/foo and cifs/foo.domain) by which the server can be
> > resolved. 
> > 
> 
> Ok, to summarize:
> 
> Andrew says that there's no reason to ever try to get anything but
> a "cifs/" principal. In the case of an unqualified hostname, we should
> try to get a "cifs/" principal with the given hostname first, and then
> append a guessed domain name if that fails.
> 
> Simo are you in agreement here? Or can you think of any cases where we
> should try to do anything different?
> 
> Another question:
> 
> Most KDC's are case-sensitive, but DNS is generally case-insensitive.
> Should we attempt to convert the hostname to all-lowercase when
> constructing the principal name to use? I don't think we want to
> encourage admins to put in principals for all possible combinations of
> upper and lower case...

Indeed, this insane solution is what users of MIT kerberos KDCs have
resorted to, to deal with upper/lower case combinations entered on
windows clients. 

converting all hostnames to all-lowercase seems quite reasonable to me.

Andrew Bartlett

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org