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