Issue with FreeIPA integration

TrueNAS General
,
1

I’ve followed the instructions for attaching my TrueNAS Scale 24.10.2.1 to my FreeIPA domain.

Note: I’ve had this domain for several years, and have previously used scratch built NAS servers from RHEL9. I know my setup works, it’s still working today.

The built in support mostly works, but someone made a design decision along the way that makes no sense to me. Someone decided, that even though we are attaching ourselves to a FreeIPA domain, they would still write the smb4.conf file to use a local database for the password backend. This means that only the local accounts can login to the SMB server using login/passwd credentials, and all the IPA users must use kerberos tickets. This is quite the PITA for all of the Mac and Windows computers as joining them to a FreeIPA domain is a manual slog. But if they just used the ldap server as the password backend, then logging into the smb server using the FreeIPA credentials “just works”, even without a kerberos ticket.

The only reason I can ever imagine for doing things the way they did is if you have a split brain user management scenario, which is almost always a super bad idea. Have an admin account, and possibly a root account, on your NAS, but every other account should come from your single source of truth (LDAP, AD, whatever) and only those accounts should have user login access to the shares. The admin accounts only need access to the web interface, ssh, and cli. Which they still have.

So, although I would consider this design choice a bug, if someone really wants to run split brain user management, the current design allows for it in a really clunky and horrible way. But for those of us that don’t want to participate in this masochistic user management scenario, maybe a button on the Advanced LDAP or advanced SMB screens that says “Use directory server/ldap for SMB accounts” and in so doing would redirect the smb4.conf away from a local password database and to the correct directory server, thereby making password based logins for AD/LDAP/FreeIPA accounts “just work”.

2

Basically we’re following standard freeipa deployment scripts for installing SMB server support on a client server:

I’m open to listening to particular suggestions for improvements.

Generally though, the industry is moving away from allowing NTLM authentication. pdb_ldapsam is particularly bad as it would mean that the TrueNAS server as an LDAP client has access to unsalted MD4s of all domain accounts (I don’t think we’d ever allow this as a supported configuration).

4

These are all of the relevant settings that ipa-server-install configured in the samba config on an actual IPA server running also as an SMB server:

    kerberos method = dedicated keytab
    dedicated keytab file = /etc/samba/samba.keytab
    create krb5 conf = no
    server role = IPA PRIMARY DOMAIN CONTROLLER
    security = user
    domain master = yes
    domain logons = yes
    log level = 1
    max log size = 100000
    log file = /var/log/samba/log.%m
    passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket
    ldapsam:trusted = yes
    ldap ssl = off
    ldap suffix = dc=example,dc=com
    ldap user suffix = cn=users,cn=accounts
    ldap group suffix = cn=groups,cn=accounts
    ldap machine suffix = cn=computers,cn=accounts
    idmap config * : backend = tdb
    idmap config * : range = 0 - 0
    idmap config EXAMPLE : backend = sss
    idmap config EXAMPLE : range = 2200 - 202200
    server min protocol = SMB2

Obviously, a socket won’t work for a remote IPA server, you would have to use an ip address/hostname instead, and I would switch ldap ssl to starttls instead of off. But this otherwise works. Are you saying that the ipasam:ldapi: passdb backend gets unsalted access to MD4 hashes? I don’t know if ipasam:ldapi: is handled the same as pdb_ldapsam, so I can’t say if this setup has the same problem. However, moving away from NTLM means, unless I’m mistaken, that no machine can access the shares without one of three things: an AD server and the machine registered with that server and the user using a mobile account, an LDAP server and the machine registered with kerberos and the user having a mobile account, or doing local accounts on the TrueNAS box (and as I have three of these boxes I use to geographically disperse my backups for disaster recovery reasons, that’s a non-starter for me). The “every machine must be part of either an AD or LDAP domain in order to access shares” is also a PITA for me because, while the linux machines can join the FreeIPA domain almost effortlessly, both Windows and Mac machines are quite the pain to register to the domain and convert local accounts to mobile accounts. And for those of us that are home users and not full enterprise organizations with dedicated IT departments, that Windows/Mac burden is excessive IMO.

But, like I mentioned, I’d be fine with just a checkbox on either the LDAP or SMB advanced screen that said “Use AD/LDAP for SMB authentication” and only set this if that flag is checked.

5

Also, I should mention that the IPA setup sets other options too, I just pulled out all the ones I thought might be relevant and skipped the others.

6

That’s the key part. Your IPA server is acting as basically an NT domain controller at that point.

Are you saying that the ipasam:ldapi: passdb backend gets unsalted access to MD4 hashes?

Yes. That’s how this generally works. It means that a compromised filer could be relatively trivially used as a stepping stone to compromising the IPA domain, which is why we don’t support this configuration.

SMB + KRB and NFS +KRB work in TrueNAS in IPA domains, but we’re not going to go out of our way to introduce support for insecure hacks to allow dangerous configurations.

For reference, see ipasam_nthash_retrieve().

7

Are the unsalted md4 hashes part of the NTLM protocol or part of the communications between the samba server and the LDAP server?

8

Are the unsalted md4 hashes part of the NTLM protocol or part of the communications between the samba server and the LDAP server?

This is communication between the samba server and the LDAP component of FreeIPA. The samba server then uses the NT hash to do ntlm authentication. This is a significantly different behavior than NTLM authentication in an AD domain (where authentication is basically passed through to the DC).

9

I’m trying to decide whether or not I agree with your statement “to introduce support for insecure hacks to allow dangerous configurations”. So, when the FreeIPA server is also the SMB master domain server, it uses an insecure socket on the machine, but that could just as easily be used to snag the unhashed md4 hashes as in the setting you mention. However, you didn’t call it an insecure hack. This implies, to me at least, that you consider the main FreeIPA server to be in a higher security class than the TrueNAS server. It’s like you expect the TrueNAS server to be more vulnerable and because of that, things that are OK on the FreeIPA server are not acceptable to the TrueNAS server. I don’t think I agree with that. The FreeIPA server runs a web server that is decidedly more general and open than the TrueNAS administrative interface. The FreeIPA server (used to, but doesn’t any more) runs a sendmail instance that accepted mail from the Internet, and a Dovecot instance that provided pop, imap, and managesieve interfaces to the Internet. The FreeIPA server was actually at significantly higher risk than the TrueNAS boxes are today. The TrueNAS boxes are 100% firewalled off with no ports exposed to the Internet. The FreeIPA server is still exposing ports to the Internet. So, in truth, my primary ingress point for any nefarious entity would be the FreeIPA box, where your claim that the TrueNAS box could be used as a jumping point to get to the IPA server is actually the opposite of reality. This is probably mostly true for typical home users.

By contrast, getting Mac OS X hooked into FreeIPA is something that I can’t even find a definitive guide to on the Internet. Lots of people have tried, they’ve had varying degrees of success, and none of them can claim to have 100% succeeded. Part of the problem is Apple’s own lack of support for LDAP accounts as they retire their own Server.app and move away from these setups.

Similarly, Windows computers are also a pain. Not as bad as Macs, but still a pain.

And this is when you have to ask the question that all this begs: Are you (and here I mean iX Systems) making security requirements too onerous such that it pushes people away from good security practices. The level of requirements you are imposing are reasonable for corporate type environments where they have an IT department. And if that’s the only market you care about, then I would say your position is fine. But, if you want to also support those of us that are home users and don’t have a dedicated IT staff, and in fact need to do our day jobs instead of spending hours trying to work through things that don’t have established solutions available, then I would argue this setup is suboptimal, and for an environment like mine, a requirement of kerberos is overkill. Is it more secure? Yes. Am I a target of concerted hacking efforts that make the lower level of security a major issue, especially since my TrueNAS boxes are 100% firewalled off with no exposed ports? I would argue not. So, for my specific configuration, I don’t think the issue you’ve brought up is a real issue.

And, actually, I would be fine if you just allowed someone like myself to make hand edits that are sticky. The fact that you rewrite the samba config on every startup of the service prevents me from making things work.

I know you said the industry is moving away from all NTLM authentication. I would argue that this is a very enterprise centric and myopic view. They may be doing that there, but the regular home user that would normally get a QNap or Synology device is not doing so. I would think it all really boils down to whether or not you guys want to support that smaller market, and if so, then I would argue that the setting I suggested is not an “insecure hacks” but is a reasonable level of care for the given use case and environment.