logo_kerberos.gif

Difference between revisions of "Samba4 Port: iptables Remapping"

From K5Wiki
Jump to: navigation, search
(New page: Q: background: i was hired by RH to port Samba4 (an OSS replacement for active directory) from heimdal-krb to mit-krb. Q: the samba4 people have built their AD-surrogate server (cal...)
 
 
(8 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;
  +
* 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?
 
without reimplementing the TCP/IP stack?
Q: i'm told that tun/tap kernel modules might help, but i dunno.
+
I'm told that tun/tap kernel modules might help, but I dunno.
Q: one asset in my favor: the kdc knows how to deliver krb service
+
One asset in my favor: the kdc knows how to deliver krb service
via udp; though AD clients use only tcp-mediated krb-service.
+
via UDP; though AD clients use only TCP-mediated krb-service.
A: iptables redirection? iptables can take a port and redirect it
+
A: you can also tunnel between machines with ipsec
+
A: How about:
Q: ipsec seems to me a heavyweight solution; am i missing something?
+
* iptables redirection: iptables can take a port & redirect it.
A: xinetd can also do redirection and tunneling
+
* IPSec can tunnel between machines.
Q: oh, really?
+
* xinetd can do redirection and tunneling
A: sshd or stunnel can do it
+
* sshd or stunnel can do it (stunnel might be better than sshd).
A: stunnel might be better than sshd
+
Q: So you're saying, the samba4 server catches (readrecv()) the
Q: so you're saying, the samba4 server catches (readrecv()) the
 
 
client's kdc-request, and the samba4 server can then tunnel
 
client's kdc-request, and the samba4 server can then tunnel
 
the client's request to the kdc, inside some other IPC-
 
the client's request to the kdc, inside some other IPC-
 
connection protocol, so that the client & the kdc don't know
 
connection protocol, so that the client & the kdc don't know
about the tunnel?
+
about the tunnel? is this easy to set up?
Q: is this easy to set up?
+
A: I was thinking iptables could probably do the proxy work and
A: i was thinking iptables could probably do the proxy work and
 
 
send the packet to another machine.
 
send the packet to another machine.
 
if that doesn't work, then xinetd might be possible
 
if that doesn't work, then xinetd might be possible
Q: the samba4 people really-really want everything on one host;
+
Q: The Samba4 people really-really want everything on one host;
 
ease-of-administration is one of their selling-points.
 
ease-of-administration is one of their selling-points.
A: the only issue with doing it in iptables that you have to
+
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
 
make sure not to delete tha NAT rules when locking down the
 
system
 
system
Q: but having a host-to-host tunnel solution available for
+
Q: But having a host-to-host tunnel solution available for
 
krb-admins who want it, would be good from MIT's POV, and
 
krb-admins who want it, would be good from MIT's POV, and
 
might be acceptable to the samba4 people, as non-default
 
might be acceptable to the samba4 people, as non-default
 
behavior.
 
behavior.
A: would the traffic be something you wouldn't want 3rd parties
+
A: Would the traffic be something you wouldn't want 3rd parties
 
to see? in other words, clear text or encrypted?
 
to see? in other words, clear text or encrypted?
Q: doesn't matter; the krb protocol is GRAS (generally recognized
+
Q: Doesn't matter; the krb protocol is GRAS (generally recognized
 
as safe).
 
as safe).
Q: a curlicue is that in unix krb deployments, the kdc ignores
 
 
A: xinetd would add some overhead.
the client's ip-address for authentication purposes, but for
 
 
Q: I believe kdc performance isn't a critical issue in Samba
AD, the kdc usually enforces access-control on the client's
 
IP-address. this means that the tunnel needs to present the
 
krb-protocol packets to the kdc, with the client's source-
 
address intact.
 
A: xinetd will 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
 
deployments; AD users typically deply 1 AD-server per subnet
 
or per building, so it's rare for an AD server to see heavy
 
or per building, so it's rare for an AD server to see heavy
 
kdc-traffic.
 
kdc-traffic.
Q: in unix-based krb deployments, you usually see 1 master kdc
+
Q: In unix-based krb deployments, you usually see 1 master kdc
 
& a couple slaves handling a large organization (thousands
 
& a couple slaves handling a large organization (thousands
of user-accounts).
+
of user-accounts). So in unix deployments, performance-hits
Q: so in unix deployments, performance-hits would be bad.
+
would be bad.
A: sounds like kernel-level redirection might be best
+
A: Sounds like kernel-level redirection (iptable-remapping)
Q: kernel-level redirect is the iptable-remapping option?
+
might be best. you need to use the routing capabilities of
A: yes; you would want to use the routing capabilities of the
+
the linux kernel.
linux kernel
+
A: So the samba-server-host would be a router for the kdc port.
A: so the samba server would be a router for the kdc port.
+
Q: Is this feature universal across linux distros?
A: samba server is a bad word, the machine with the samba server
+
A: Yes; linux makes for a very good router; Cisco uses it for
is better
+
low-end models
Q: is this feature universal across linux distros?
+
Q: Do I have hope of seeing this feature on Solaris or on *bsd?
A: yes
+
A: I think most Unix boxes can act as routers.
A: linux makes for a very good router
+
A: What you are wanting to do is to route just one port and
Q: do i have hope of seeing this feature on solaris or on *bsd?
+
leave others alone.
A: cisco uses it for low end models
+
Q: I think so; I believe the Samba service catches different
A: I think most unix can act as routers
 
A: what you are wanting to do is 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.
 
services on different ports, as usual.
A: if that's the case, it should be easy
+
A: If that's the case, it should be easy
Q: so you're suggesting that the samba server can route kdc
+
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,
 
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
 
in such a way that the client doesn't have to know the kdc's
real ip-address / port?
+
real IP-address / port?
A: yes
+
A: Yes
Q: and in such a way that the kdc does see the client's real
+
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
+
IP-address, just as if the kdc readrecv()'ed the client's
 
original kdc-request-packet?
 
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