logo_kerberos.gif

Difference between revisions of "Samba4 Port: iptables Remapping"

From K5Wiki
Jump to: navigation, search
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
Q: background: i was hired by RH to port Samba4 (an OSS replacement
 
  +
<pre>
for active directory) from heimdal-krb to mit-krb.
+
Q: Background problem: to port Samba4 from Heimdal-krb to MIT-krb.
Q: the samba4 people have built their AD-surrogate server
+
Samba4 is an open-source replacement for Active Directory.
(called Samba), configured to use the heimdal kdc via a library
+
interface, so that the kdc runs in the same process as all of
+
Foreground problem:
the other AD services (SMB, netlogon, cifs, samr, etc). the
+
* Samba, the AD-surrogate server, uses the Heimdal KDC via a
samba4 people repeatedly insist that they won't accept an MIT
+
library interface, so that the KDC runs in the same process
integration that doesn't work in exactly the same way.
+
as all of the other AD services (SMB, netlogon, cifs, samr,
Q: mit-krb people respond that spec'ing such a libkdc interface,
+
etc).
getting community approval, and building it will take "a long
+
* The Samba4 people repeatedly insist that they won't accept
time".
+
an MIT integration that doesn't work in exactly the same way.
Q: i'm between a rock & a hard place, and i'm looking for a better
+
* The MIT-krb people respond that spec'ing such a libkdc
solution.
+
interface, getting approval from the krbdev community, and
Q: specifically, i believe the samba4 people aren't so much devoted
+
building the libkdc interface will take "a long time".
to their libkdc approach; they might accept an alternate solution,
+
as long as both mit & heimdal kdc will work identically with that
+
Part of the technical disagreement is two conflicting realities:
solution.
+
* Unix deployments of MIT-krb take it for granted that you don't
Q: part of the technical disagreement is two conflicting realities:
+
run non-kdc services on the same box that hosts a kdc; while
unix deployments of mit-krb take it for granted that you don't
+
* Samba4 people know that Windows clients inflexibly expect that
run non-kdc services on the same box that hosts a kdc; while
+
kdc, cifs, netlogon, ntlm, samr, etc all have to be served
samba4 people know that windows clients inflexibly expect the
+
from the same ip-address.
kdc, cifs, netlogon ntlm, samr, etc all have to be served from
+
the same ip-address.
+
So, I'm looking for a better solution.
Q: so, here's what i'm hoping can be made to work: i want to keep
+
Specifically, I believe the Samba4 people are more devoted to
the samba4 kdc (heimdal or mit's) in a separate process on the
+
uniformity than to their libkdc approach; they might accept
samba-server host;
+
an alternate solution, as long as both MIT-krb & Heimdal kdc
Q: when the samba server catches a client request for AD-style krb-
+
will work identically with that one solution. So, here's what
service, i want the samba server to pretend that it is tunnelling
+
I'm hoping can be made to work:
the client request to the kdc, via an IPC connection.
+
* I want to keep the Samba4 kdc (Heimdal or MIT's) in a
Q: is there some way to make this pseudo-tunnelled approach work,
+
separate process on the Samba-server host;
without reimplementing the TCP/IP stack?
+
* When the Samba server catches a client request for AD-style
Q: i'm told that tun/tap kernel modules might help, but i dunno.
+
krb-service, I want the Samba server to pretend that it is
Q: one asset in my favor: the kdc knows how to deliver krb service
+
tunnelling the client request to the kdc, via an IPC connection.
via udp; though AD clients use only tcp-mediated krb-service.
+
* The kdc needs to receive the krb-protocol packets with the
A: iptables redirection? iptables can take a port and redirect it
+
client's source-address intact. in unix krb deployments,
A: you can also tunnel between machines with ipsec
+
the kdc ignores the client's IP-address for authentication
Q: ipsec seems to me a heavyweight solution; am i missing something?
+
purposes, but for AD, the kdc usually enforces access-control
A: xinetd can also do redirection and tunneling
+
on the client's IP-address.
Q: oh, really?
+
Is there some way to make this pseudo-tunnelled approach work,
A: sshd or stunnel can do it
+
without reimplementing the TCP/IP stack?
A: stunnel might be better than sshd
+
I'm told that tun/tap kernel modules might help, but I dunno.
Q: so you're saying, the samba4 server catches (readrecv()) the
+
One asset in my favor: the kdc knows how to deliver krb service
client's kdc-request, and the samba4 server can then tunnel
+
via UDP; though AD clients use only TCP-mediated krb-service.
the client's request to the kdc, inside some other IPC-
+
connection protocol, so that the client & the kdc don't know
+
A: How about:
about the tunnel?
+
* iptables redirection: iptables can take a port & redirect it.
Q: is this easy to set up?
+
* IPSec can tunnel between machines.
A: i was thinking iptables could probably do the proxy work and
+
* xinetd can do redirection and tunneling
send the packet to another machine.
+
* sshd or stunnel can do it (stunnel might be better than sshd).
if that doesn't work, then xinetd might be possible
+
Q: So you're saying, the samba4 server catches (readrecv()) the
Q: the samba4 people really-really want everything on one host;
+
client's kdc-request, and the samba4 server can then tunnel
ease-of-administration is one of their selling-points.
+
the client's request to the kdc, inside some other IPC-
A: the only issue with doing it in iptables that you have to
+
connection protocol, so that the client & the kdc don't know
make sure not to delete tha NAT rules when locking down the
+
about the tunnel? is this easy to set up?
system
+
A: I was thinking iptables could probably do the proxy work and
Q: but having a host-to-host tunnel solution available for
+
send the packet to another machine.
krb-admins who want it, would be good from MIT's POV, and
+
if that doesn't work, then xinetd might be possible
might be acceptable to the samba4 people, as non-default
+
Q: The Samba4 people really-really want everything on one host;
behavior.
+
ease-of-administration is one of their selling-points.
A: would the traffic be something you wouldn't want 3rd parties
+
A: The only issue with doing it in iptables is that you have to
to see? in other words, clear text or encrypted?
+
make sure not to delete tha NAT rules when locking down the
Q: doesn't matter; the krb protocol is GRAS (generally recognized
+
system
as safe).
+
Q: But having a host-to-host tunnel solution available for
Q: a curlicue is that in unix krb deployments, the kdc ignores
+
krb-admins who want it, would be good from MIT's POV, and
the client's ip-address for authentication purposes, but for
+
might be acceptable to the samba4 people, as non-default
AD, the kdc usually enforces access-control on the client's
+
behavior.
IP-address. this means that the tunnel needs to present the
+
A: Would the traffic be something you wouldn't want 3rd parties
krb-protocol packets to the kdc, with the client's source-
+
to see? in other words, clear text or encrypted?
address intact.
+
Q: Doesn't matter; the krb protocol is GRAS (generally recognized
A: xinetd will add some overhead
+
as safe).
Q: i believe kdc performance isn't a critical issue in samba
+
A: xinetd would add some overhead.
deployments; AD users typically deply 1 AD-server per subnet
+
Q: I believe kdc performance isn't a critical issue in Samba
or per building, so it's rare for an AD server to see heavy
+
deployments; AD users typically deply 1 AD-server per subnet
kdc-traffic.
+
or per building, so it's rare for an AD server to see heavy
Q: in unix-based krb deployments, you usually see 1 master kdc
+
kdc-traffic.
& a couple slaves handling a large organization (thousands
+
Q: In unix-based krb deployments, you usually see 1 master kdc
of user-accounts).
+
& a couple slaves handling a large organization (thousands
Q: so in unix deployments, performance-hits would be bad.
+
of user-accounts). So in unix deployments, performance-hits
A: sounds like kernel-level redirection might be best
+
would be bad.
Q: kernel-level redirect is the iptable-remapping option?
+
A: Sounds like kernel-level redirection (iptable-remapping)
A: yes; you would want to use the routing capabilities of the
+
might be best. you need to use the routing capabilities of
linux kernel
+
the linux kernel.
A: so the samba server would be a router for the kdc port.
+
A: So the samba-server-host would be a router for the kdc port.
A: samba server is a bad word, the machine with the samba server
+
Q: Is this feature universal across linux distros?
is better
+
A: Yes; linux makes for a very good router; Cisco uses it for
Q: is this feature universal across linux distros?
+
low-end models
A: yes
+
Q: Do I have hope of seeing this feature on Solaris or on *bsd?
A: linux makes for a very good router
+
A: I think most Unix boxes can act as routers.
Q: do i have hope of seeing this feature on solaris or on *bsd?
+
A: What you are wanting to do is to route just one port and
A: cisco uses it for low end models
+
leave others alone.
A: I think most unix can act as routers
+
Q: I think so; I believe the Samba service catches different
A: what you are wanting to do is route just one port and leave
+
services on different ports, as usual.
others alone
+
A: If that's the case, it should be easy
Q: i think so; i believe the samba service catches different
+
Q: So you're suggesting that the Samba server can route kdc
services on different ports, as usual.
+
traffic to the kdc, on the same host or on a different host,
A: if that's the case, it should be easy
+
in such a way that the client doesn't have to know the kdc's
Q: so you're suggesting that the samba server can route kdc
+
real IP-address / port?
traffic to the kdc, on the same host or on a different host,
+
A: Yes
in such a way that the client doesn't have to know the kdc's
+
Q: And in such a way that the kdc does see the client's real
real ip-address / port?
+
IP-address, just as if the kdc readrecv()'ed the client's
A: yes
+
original kdc-request-packet?
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: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html#ss4.5
 
A: ^^^ might be useful
 
A: ^^^ might be useful
A: now the question is did it make it into iptables mainline by now
+
A: Now the question is did it make it into iptables mainline by now
  +
</pre>

Latest revision as of 14:59, 31 August 2009

Q: Background problem: to port Samba4 from Heimdal-krb to MIT-krb.
   Samba4 is an open-source replacement for Active Directory. 

   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 & redirect it.  
   * IPSec can tunnel between machines.
   * xinetd can 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