Difference between revisions of "Samba4 Port: iptables Remapping"
From K5Wiki
| (One intermediate revision by the same user not shown) | |||
| Line 44: | Line 44: | ||
A: How about: |
A: How about: |
||
| − | * iptables redirection: |
+ | * iptables redirection: iptables can take a port & redirect it. |
| − | + | * IPSec can tunnel between machines. |
|
| − | * xinetd can |
+ | * xinetd can do redirection and tunneling |
* sshd or stunnel can do it (stunnel might be better than sshd). |
* sshd or stunnel can do it (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 |
||
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
