Difference between revisions of "Samba4 Port: iptables Remapping"

Revision as of 14:40, 31 August 2009

Q: Background problem to solve: to port Samba4 (an OSS replacement
   for Active Directory) from Heimdal-krb to MIT-krb. 

   Foreground problem:  
   * Samba, the AD-surrogate server, uses the Heimdal KDC via a 
     library interface, so that the KDC runs in the same process 
     as all of the other AD services (SMB, netlogon, cifs, samr, 
     etc).  
   * The Samba4 people repeatedly insist that they won't accept 
     an MIT integration that doesn't work in exactly the same way.
   * The MIT-krb people respond that spec'ing such a libkdc 
     interface, getting approval from the krbdev community, and 
     building the libkdc interface will take "a long time".
   
   Part of the technical disagreement is two conflicting realities:  
   * Unix deployments of MIT-krb take it for granted that you don't 
     run non-kdc services on the same box that hosts a kdc; while
   * Samba4 people know that Windows clients inflexibly expect that
     kdc, cifs, netlogon, ntlm, samr, etc all have to be served 
     from the same ip-address.

   So, I'm looking for a better solution.
   Specifically, I believe the Samba4 people are more devoted to 
   uniformity than to their libkdc approach;  they might accept 
   an alternate solution, as long as both MIT-krb & Heimdal kdc 
   will work identically with that one solution.  So, here's what 
   I'm hoping can be made to work:  
   * I want to keep the Samba4 kdc (Heimdal or MIT's) in a 
     separate process on the Samba-server host;
   * When the Samba server catches a client request for AD-style 
     krb-service, I want the Samba server to pretend that it is 
     tunnelling the client request to the kdc, via an IPC connection.
   * The kdc needs to receive the krb-protocol packets with the 
     client's source-address intact.  in unix krb deployments, 
     the kdc ignores the client's IP-address for authentication 
     purposes, but for AD, the kdc usually enforces access-control 
     on the client's IP-address. 
   Is there some way to make this pseudo-tunnelled approach work,
   without reimplementing the TCP/IP stack?
   I'm told that tun/tap kernel modules might help, but I dunno.
   One asset in my favor:  the kdc knows how to deliver krb service
   via UDP; though AD clients use only TCP-mediated krb-service. 
 
A: How about:
   * iptables redirection:  iptables can take a port and redirect
     it.  You can also tunnel between machines with ipsec.
   * xinetd can also do redirection and tunneling
   * sshd or stunnel can do it (stunnel might be better than sshd).
Q: So you're saying, the samba4 server catches (readrecv()) the
   client's kdc-request, and the samba4 server can then tunnel
   the client's request to the kdc, inside some other IPC-
   connection protocol, so that the client & the kdc don't know
   about the tunnel?  is this easy to set up?
A: I was thinking iptables could probably do the proxy work and
   send the packet to another machine.
   if that doesn't work, then xinetd might be possible
Q: The Samba4 people really-really want everything on one host;
   ease-of-administration is one of their selling-points.
A: The only issue with doing it in iptables is that you have to
   make sure not to delete tha NAT rules when locking down the
   system
Q: But having a host-to-host tunnel solution available for
   krb-admins who want it, would be good from MIT's POV, and
   might be acceptable to the samba4 people, as non-default
   behavior.
A: Would the traffic be something you wouldn't want 3rd parties
   to see?  in other words, clear text or encrypted?
Q: Doesn't matter;  the krb protocol is GRAS (generally recognized
   as safe).
A: xinetd would add some overhead.
Q: I believe kdc performance isn't a critical issue in Samba
   deployments;  AD users typically deply 1 AD-server per subnet
   or per building, so it's rare for an AD server to see heavy
   kdc-traffic.
Q: In unix-based krb deployments, you usually see 1 master kdc
   & a couple slaves handling a large organization (thousands
   of user-accounts).  So in unix deployments, performance-hits 
   would be bad.
A: Sounds like kernel-level redirection (iptable-remapping) 
   might be best.  you need to use the routing capabilities of 
   the linux kernel.
A: So the samba-server-host would be a router for the kdc port.
Q: Is this feature universal across linux distros?
A: Yes;  linux makes for a very good router;  Cisco uses it for 
   low-end models
Q: Do I have hope of seeing this feature on Solaris or on *bsd?
A: I think most Unix boxes can act as routers.
A: What you are wanting to do is to route just one port and 
   leave others alone.
Q: I think so;  I believe the Samba service catches different
   services on different ports, as usual.
A: If that's the case, it should be easy
Q: So you're suggesting that the Samba server can route kdc
   traffic to the kdc, on the same host or on a different host,
   in such a way that the client doesn't have to know the kdc's
   real IP-address / port?
A: Yes
Q: And in such a way that the kdc does see the client's real
   IP-address, just as if the kdc readrecv()'ed the client's
   original kdc-request-packet?
A: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html#ss4.5
A: ^^^ might be useful
A: Now the question is did it make it into iptables mainline by now