Samba4 Port: iptables Remapping - Revision history

Don at 19:59, 31 August 2009

2009-08-31T19:59:43Z

Don at 19:58, 31 August 2009

2009-08-31T19:58:55Z

Don at 19:42, 31 August 2009

2009-08-31T19:42:15Z

Don at 19:40, 31 August 2009

2009-08-31T19:40:20Z

Don at 19:17, 31 August 2009

2009-08-31T19:17:00Z

Don at 19:14, 31 August 2009

2009-08-31T19:14:24Z

Don at 19:07, 31 August 2009

2009-08-31T19:07:26Z

Show changes

Don at 18:48, 31 August 2009

2009-08-31T18:48:21Z

Don at 18:44, 31 August 2009

2009-08-31T18:44:54Z

Don: 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...

2009-08-31T18:44:06Z

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...

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
(called Samba), configured to use 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.
Q: mit-krb people respond that spec'ing such a libkdc interface,
getting community approval, and building it will take "a long
time".
Q: i'm between a rock & a hard place, and i'm looking for a better
solution.
Q: specifically, i believe the samba4 people aren't so much devoted
to their libkdc approach; they might accept an alternate solution,
as long as both mit & heimdal kdc will work identically with that
solution.
Q: 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 the
kdc, cifs, netlogon ntlm, samr, etc all have to be served from
the same ip-address.
Q: 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;
Q: 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.
Q: is there some way to make this pseudo-tunnelled approach work,
without reimplementing the TCP/IP stack?
Q: 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
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
Q: ipsec seems to me a heavyweight solution; am i missing something?
A: xinetd can also do redirection and tunneling
Q: oh, really?
A: sshd or stunnel can do it
A: 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?
Q: 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 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).
Q: a curlicue is that 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. 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
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).
Q: so in unix deployments, performance-hits would be bad.
A: sounds like kernel-level redirection might be best
Q: kernel-level redirect is the iptable-remapping option?
A: yes; you would want to use the routing capabilities of the
linux kernel
A: so the samba server would be a router for the kdc port.
A: samba server is a bad word, the machine with the samba server
is better
Q: is this feature universal across linux distros?
A: yes
A: linux makes for a very good router
Q: do i have hope of seeing this feature on solaris or on *bsd?
A: cisco uses it for low end models
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.
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

@@ Line 45: / Line 45: @@
 A: How about:
    * iptables redirection: iptables can take a port & redirect it.
-   * You can also tunnel between machines with ipsec.
+   * IPSec can tunnel between machines.
-   * xinetd can also do redirection and tunneling
+   * 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

@@ Line 44: / Line 44: @@
 A: How about:
-   * iptables redirection:  iptables can take a port and redirect
+   * iptables redirection: iptables can take a port & redirect it.
-     it.  You can also tunnel between machines with ipsec.
+   * 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).

@@ Line 1: / Line 1: @@
 <pre>
-Q: Background problem to solve: to port Samba4 (an OSS replacement
+Q: Background problem: to port Samba4 from Heimdal-krb to MIT-krb.
-   for Active Directory) from Heimdal-krb to MIT-krb.
+   Samba4 is an open-source replacement for Active Directory.
    Foreground problem:

@@ Line 1: / Line 1: @@
 <pre>
 Q: Background problem to solve: to port Samba4 (an OSS replacement
-   for active directory) from Heimdal-krb to MIT-krb.
+   for Active Directory) from Heimdal-krb to MIT-krb.
-   (called Samba), configured to use the Heimdal KDC via a library
+   * Samba, the AD-surrogate server, uses the Heimdal KDC via a
-   interface, so that the KDC runs in the same process as all of
+     library interface, so that the KDC runs in the same process
-   the other AD services (SMB, netlogon, cifs, samr, etc).  The
+     as all of the other AD services (SMB, netlogon, cifs, samr,
-   Samba4 people repeatedly insist that they won't accept an MIT
+     etc).
-   integration that doesn't work in exactly the same way.
+   * The Samba4 people repeatedly insist that they won't accept
-   The MIT-krb people respond that spec'ing such a libkdc interface,
+     an MIT integration that doesn't work in exactly the same way.
-   getting approval from the krbdev community, and building the
+   * The MIT-krb people respond that spec'ing such a libkdc
-   libkdc interface will take "a long time".
+     interface, getting approval from the krbdev community, and
    Part of the technical disagreement is two conflicting realities:
-   * Unix deployments of MIT-krb take it for granted that you
+   * Unix deployments of MIT-krb take it for granted that you don't
-     don't run non-kdc services on the same box that hosts a kdc;
+     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
@@ Line 21: / Line 21: @@
    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
+   uniformity than to their libkdc approach;  they might accept
-   alternate solution, as long as both MIT-krb & Heimdal kdc will
+   an alternate solution, as long as both MIT-krb & Heimdal kdc
-   work identically with that one solution.
+   will work identically with that one solution.  So, here's what
-   So, here's what I'm hoping can be made to work:
+   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;
@@ Line 30: / Line 30: @@
      krb-service, I want the Samba server to pretend that it is
      tunnelling the client request to the kdc, via an IPC connection.
-     the client's ip-address for authentication purposes, but for
+     client's source-address intact.  in unix krb deployments,
-     AD, the kdc usually enforces access-control on the client's
+     the kdc ignores the client's IP-address for authentication
-     IP-address.  this means that the tunnel needs to present the
+     purposes, but for AD, the kdc usually enforces access-control
-     krb-protocol packets to the kdc, with the client's source-
+     on the client's IP-address.
    Is there some way to make this pseudo-tunnelled approach work,
    without reimplementing the TCP/IP stack?
@@ Line 67: / Line 67: @@
 Q: Doesn't matter;  the krb protocol is GRAS (generally recognized
    as safe).
-A: xinetd wouldl add some overhead.
+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
@@ Line 76: / Line 76: @@
    of user-accounts).  So in unix deployments, performance-hits
    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.
 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.
+A: Yes;  linux makes for a very good router;  Cisco uses it for
-A: Cisco uses it for low-end models
+   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: 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.

@@ Line 13: / Line 13: @@
    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
+   * Unix deployments of MIT-krb take it for granted that you
-   run non-kdc services on the same box that hosts a kdc;  while
+     don't run non-kdc services on the same box that hosts a kdc;
-   samba4 people know that windows clients inflexibly expect the
+     while
-   kdc, cifs, netlogon ntlm, samr, etc all have to be served from
+   * Samba4 people know that Windows clients inflexibly expect that
-   the same ip-address.
+     kdc, cifs, netlogon, ntlm, samr, etc all have to be served
    So, I'm looking for a better solution.

@@ Line 1: / Line 1: @@
 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
-(called Samba), configured to use the heimdal kdc via a library
+   (called Samba), configured to use the heimdal kdc via a library
-interface, so that the kdc runs in the same process as all of
+   interface, so that the kdc runs in the same process as all of
-the other AD services (SMB, netlogon, cifs, samr, etc).  the
+   the other AD services (SMB, netlogon, cifs, samr, etc).  the
-samba4 people repeatedly insist that they won't accept an MIT
+   samba4 people repeatedly insist that they won't accept an MIT
-integration that doesn't work in exactly the same way.
+   integration that doesn't work in exactly the same way.
 Q: mit-krb people respond that spec'ing such a libkdc interface,
-getting community approval, and building it will take "a long
+   getting community approval, and building it will take "a long
-time".
+   time".
 Q: i'm between a rock & a hard place, and i'm looking for a better
-solution.
+   solution.
 Q: specifically, i believe the samba4 people aren't so much devoted
-to their libkdc approach;  they might accept an alternate solution,
+   to their libkdc approach;  they might accept an alternate solution,
-as long as both mit & heimdal kdc will work identically with that
+   as long as both mit & heimdal kdc will work identically with that
-solution.
+   solution.
 Q: part of the technical disagreement is two conflicting realities:
-unix deployments of mit-krb take it for granted that you don't
+   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
+   run non-kdc services on the same box that hosts a kdc;  while
-samba4 people know that windows clients inflexibly expect the
+   samba4 people know that windows clients inflexibly expect the
-kdc, cifs, netlogon ntlm, samr, etc all have to be served from
+   kdc, cifs, netlogon ntlm, samr, etc all have to be served from
-the same ip-address.
+   the same ip-address.
 Q: 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
+   the samba4 kdc (heimdal or mit's) in a separate process on the
-samba-server host;
+   samba-server host;
 Q: when the samba server catches a client request for AD-style krb-
-service, i want the samba server to pretend that it is tunnelling
+   service, i want the samba server to pretend that it is tunnelling
-the client request to the kdc, via an IPC connection.
+   the client request to the kdc, via an IPC connection.
 Q: 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.
 Q: 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
@@ Line 41: / Line 42: @@
 A: 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
+   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?
 Q: is this easy to set up?
 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;
-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
-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
-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
-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
-as safe).
+   as safe).
 Q: a curlicue is that in unix krb deployments, the kdc ignores
-the client's ip-address for authentication purposes, but for
+   the client's ip-address for authentication purposes, but for
-AD, the kdc usually enforces access-control on the client's
+   AD, the kdc usually enforces access-control on the client's
-IP-address.  this means that the tunnel needs to present the
+   IP-address.  this means that the tunnel needs to present the
-krb-protocol packets to the kdc, with the client's source-
+   krb-protocol packets to the kdc, with the client's source-
-address intact.
+   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
-& a couple slaves handling a large organization (thousands
+   & a couple slaves handling a large organization (thousands
-of user-accounts).
+   of user-accounts).
 Q: so in unix deployments, performance-hits would be bad.
 A: sounds like kernel-level redirection might be best
 Q: kernel-level redirect is the iptable-remapping option?
 A: yes;  you would want to use the routing capabilities of the
-linux kernel
+   linux kernel
 A: so the samba server would be a router for the kdc port.
 A: samba server is a bad word, the machine with the samba server
-is better
+   is better
 Q: is this feature universal across linux distros?
 A: yes
@@ Line 91: / Line 92: @@
 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
+   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
 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
 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: ^^^ might be useful
 A: now the question is did it make it into iptables mainline by now