Samba4 Port: iptables Remapping

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