[Samba] Setting up Samba4 - lots of implementation questions esp re. PKI and SSO

[Paul Bradley]

I have a LOT of questions!!! This may take a while. I know some of this
stuff is at the edge of what Samba4 is just becoming able to do, so if
anyone who knows feels this is better posted on samba-technical I'd
appreciate a cross-post from someone in a position to know for sure - I did
consider posting it there straight away but I figured it's a dev list and I
could at least get _some_ of my questions answered here first maybe.

I am setting up Samba4 for SSO on a home lan with VPN access. My needs are
therefore relatively modest in terms of the more enterprise level features
of S4 (awesome stuff by the way guys - what a project), but I do want to do
some stuff like use a PKI structure with smartcards, manage group policy for
the windows clients, use kerberos for single sign on and that sort of thing.
We have a few PCs/Laptops/VMs and are setting up a VPN, so although it's not
really enterprise level stuff I am doing a few things that are "business
like" if you want to put it that way. I have mainly windows clients (Win7,
WinXP VMs) but there are one or two linux VMs that I'd also like to get the
benefits of samba4 with. I'm strongly getting the impression from reading
over the past couple of days that samba4 has just recently reached the point
of doing basically everything I need.

Servers are linux and linux-like, applications are filesharing, ssh, vpn
(probably going to be IPSEC/L2TP - haven't set that up yet, it's waiting on
the PKI, and on the kerberos for authenticating sessions to services once
the VPN connection is made), apache for a Joomla CMS and probably a couple
of other bits and pieces that I've forgotten all about.

My questions are:


- I am a little confused about the PKI implementation. Especially as regards
the particular details of how I should set up the X509 information in the
certificates. I found this:
http://middleware.internet2.edu/pki07/proceedings/slides/10-kornievskaia-pkinit-interop.pdfwhich
seems quite detailed and covers quite a bit, in particular it mentions
this:

-------QUOTE----------------------------------------------------------
CLIENT IDENTITY
- Kerberos principal name encoded in X509 SAN
- Mapping facility at the KDC
- Must have X509 EKU fields
--------/QUOTE----------------------------------------------------------

So to handle those one at a time, principal name for a user would just be
their username on the domain, or would it be the full CN like
paul at mydomain.com ?
Then for a service (I've read
http://technet.microsoft.com/en-us/library/cc961723.aspx) is the principal
name something like smb/192.168.0.1/:139/fileserver which would specify a
smb service on 192.168.0.1 on port 139 called fileserver, then fileserver
would be the name that resolved to 192.168.0.1 in the DNS? What happens with
multiple services on one server - do they all need separate keys and
certificates since they each need a different service principal name?
Perhaps it is enough to have more than one certificate each specifying a
different SPN, but all using the same key, or if I did that would there be a
security implication, since this might mean one service could masquerade as
another? How do I specify when creating the certificates with OpenSSL what
the SAN should be?

As to the second part - "Mapping facility at the KDC". I understand the KDC
needs to map the user certificate onto a username on the domain (or perhaps
more accurately some sort of GUID for the user) but how is this set up when
using PKI - do I use the Microsoft domain administration tools to connect to
Samba and bind the user certificates to the users? What about servers -
presumably their keys (now stored on disk rather than on tokens/smartcards)
also need to be in the directory so they can be mapped to the object in the
directory and participate in the kerberos or indeed do PKINIT for eg. cron
jobs which require connecting to other services?

For the third part (X509 EKU fields) - are these the "key usage" fields? The
stuff like "signing" "encryption" etc. etc.? How do I set these in OpenSSL
when creating the certificates and what should I set them too?

Also, is there much in particular I should be aware of when creating my CA?
LDAP and X509 are probably my weakest points in understanding all this - can
someone point me to a guide or give me some more information that can guide
me in deciding how to name and structure things so as to avoid potential
future issues.




Now, as to the PKINIT I presume Samba4 will interact well enough with the
native Windows PKINIT so I shouldn't have much to worry about there, but
please do correct me if I'm wrong. What about the linux clients though -
should I use CITI PKINIT ? If I do, what will happen as regards the PKCS#11
library? I have two different types of cards here, both of which seem to
work OK with the commercial middleware and tools which I have (SafeSign,
which works on both Windows and Linux) so I would want to use the SafeSign
PKCS#11 libraries, presumably the PKINIT will talk to any compliant PKCS#11
?

Once PKINIT has happened, the services then need to authenticate the peer
right, so presumably pam-krb5 is the tool for that? On the module page it
mentions working well with MIT kerberos and says that it is less tested with
Heimdal. I understand that S4 is implemented based on Heimdal so is
operation with pam-krb5 generally working now? If not, how is it done?

Having said that S4 kerberos is based on Heimdal, I wonder is the Heimdal
documentation good for guidance or is the implementation too different?

Now for IPSEC (told you this would go on a while...) - I presume IPSEC on
linux can use kerberos to authenticate the peer - does this work through
pam-krb5 again or is there some other mechanism at work?

- I'm thinking of having my fileserver be one of the DCs/KDCs. The
fileserver is probably one of the most secured machines in the whole lot
anyway. Are there any good reasons I should not do this? The way I see it,
if my KDC gets compromised the fileserver is shot anyway, and if the
fileserver (which will have stuff like KDC backups on it, mounted when it's
running which is basically always) gets compromised the KDC may as well be
considered compromised. Therefore, I don't see that much reason to separate
the two, and would simply run one DC on the fileserver and a second one on a
dedicated old box for redundancy. Any comments?

- Since the KDC is very sensitive (has it's own keys on the disk), I'd like
to consider encrypting it so that if for example it were stolen there would
be nothing to read off the disk. How would I go about setting up Samba4 to
install all the security critical stuff in /home so I could use an encrypted
home directory to protect it? I'd rather not encrypt the whole drive and use
pre-boot authentication as that would stop me being able to do remote
reboots or bring it back up after a power failure unless I was on-site.
Indeed, what even IS the security critical stuff? Presumably the directory
itself contains stuff of interest (although on the other hand, all it would
have would be public keys wouldn't it, and of course details of who could do
what and of the network structure), what about the KDC keys, where are they?
Anything else I've not thought of? Anyway, the short version of the question
is, how do I get all that stuff to install into /home so I can encrypt it
easily.

- For another rather thornier security question, and one I am leaning away
from bothering with, what about exposing kerberos to the WAN (the public
Internet) so that users can still do SSO to the VPN when off-lan? I presume
this is asking for trouble, and probably shouldn't even bother asking this,
at least not with alpha software, but I just thought it was worth opening it
up for comment. Perhaps I could even consider opening it up but only to
authenicated IPSEC sessions using certificates so only pre-authenticated
users could even begin to talk to the KDC. Any thoughts?

Thanks to anyone who actually managed to read this far - this post has gone
on longer than even I imagined it would. I guess I still have a lot to
learn, but this stuff is just plain AWESOME. Congratulations once again to
everyone who's contributed to this. Indeed, if in some way my testing and
feedback can provide more information to the developers and help with the
SSO/PKI side of things I'll be very happy to have contributed in some small
way.

Paul