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

Jeff Layton jlayton at samba.org
Tue Nov 15 06:46:20 MST 2011


On Tue, 15 Nov 2011 12:18:52 +0100
Matthieu Patou <mat at samba.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 at REALM
> > 		BAR$@REALM
> > 		host/bar.example.com at 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 at 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 at samba.org>


More information about the samba-technical mailing list