[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