5:11 p.m.
Hi Maciej,
On 06-06-19 09:27, Maciej Delmanowski wrote:
I'm starting to feel the need for a better, centralized DNS/DHCP
services as
well. Currently I'm working with two tinc VPN networks with separate subnets
and subdomains, which makes handling the resolver interesting. Having a local
unbound that redirects the requests to the correct DNS server based on the
subdomain helps, but I imagine that a central DNS that has dynamic subdomains
managed by DHCP could work better and not be confined to my workstation.
I'm looking into ISC BIND since this is what we are currently using in
production, and it nicely compliments the existing debops.dhcpd role which
uses ISC DHCPD. But I know that many DebOps users prefer PowerDNS, so if
anybody has a role for that, let me know.
Are there many Dutch DebOps users? I'm asking because PowerDNS is the
typical authoritative DNS server of every Dutch hosting company, ever.
I've worked a lot with PowerDNS software while I was an intern at such a
company, I really liked it. And I'm currently trying out the built-in
dynamic DNS update functionality with ISC DHCP server, which might prove
interesting.
Also, lead developers Bert Hubert and Peter van Dijk are just great guys.
> a SAML iDP with two-factor authentication
In Debian there's lemonldap-ng package[1] which apparently provides OpenID,
CAS and SAML support but I have no idea how popular this solution is. At work
we are using Jasig CAS which is now apparently Apereo CAS[2](?). It's not in
Debian though.
I tried LemonLDAP::NG a while ago while I was looking for SAML iDP
software, but eventually went with SimpleSAMLphp because of its
documentation and extensibility.
> an OpenVPN server (with LDAP and maybe 2FA).
Indeed, Tinc VPN currently supported in DebOps is a nice solution for internal
mesh network in a data center, but it lacks sufficient controls for authorized
access. Having OpenVPN integrated with LDAP for authentication would be nice,
but that requires use of the shared secrets, right?
I don't think so, not with the openvpn-auth-ldap package. I've been
testing a setup where I would connect OpenVPN to my LDAP server (with
TLS), and then have clients authenticate to the OpenVPN server with
their LDAP credentials. The client connection also uses TLS, and in my
case the server certificate was signed by Let's Encrypt. The clients
don't need any certificates at all, just the Let's Encrypt root in their
trust store. Using a public CA requires that clients verify the x509
subject, which can be done with something like this in the client config:
verify-x509-name 'CN=openvpn.example.com' subject
I've been looking at deploying this setup in production, but with 2FA.
Should not be too hard with YubiKeys:
https://developers.yubico.com/yubico-pam/YubiKey_and_OpenVPN_via_PAM.html
If we would want to support certificate authentication with OpenVPN,
that
would require improvement of the client certificate support in debops.pki
role. A simple set of scripts that let sysadmin generate client certs based on
the e-mail address locally on Ansible Controller, against a specific internal
CA should probably be enough for small setups, something bigger might require
a dedicated service.
Perhaps users could authenticate to a website using their LDAP credentials,
and after checking the authorization the service could generate a client
certificate for them with installation instructions provided. I wonder if
something like this exists... Probably FreeIPA and/or Dogtag PKI has something
like this built-in, but they are currently in eternal Sid basement hell since
I remember, at least a few years now (in Debian Unstable with bugs that
perpetually kick them out from current Testing release). Maybe Debian Bullseye
will be a lucky break?
Why let users authenticate with LDAP to download a client certificate
when they could just use those LDAP credentials directly in their
OpenVPN client? It wouldn't make a difference in terms of security,
unless that website would only be available from inside the company
network. But that would be another usability hurdle.
I try to prevent having end users hassle with certificates and keep the
focus on strong passwords and 2FA instead. PKI is hard ;)
Cheers,
Imre