Red Hat Identity (FreeIPA) and Samba working in TrueNAS - what is the status and is it possible?

Howard Swope

Dabbler
Joined
Nov 19, 2015
Messages
26
This worked great on FreeNas 10. I still haven't upgraded for this reason. I sure wish this would be given a real seat at the table. But the powers that be must not care about it. I have followed these threads for last 10 years and there has never been real attention given this except for one guy who was working on the FreeNAS corral project:

1634667379670.png


I sure wish it still worked this way.
 

quinn.steven

Cadet
Joined
Oct 28, 2021
Messages
1
You can use the generic LDAP plugin with FreeIPA. Several users have it deployed in production.
This is great to hear - would you mind clarifying? Can the generic LDAP plugin be used with FreeIPA for access control on SMB shares?

Thanks!
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,545
This is great to hear - would you mind clarifying? Can the generic LDAP plugin be used with FreeIPA for access control on SMB shares?

Thanks!
Depends on the context, there is additional configuration required. FreeIPA does not support NTLM authentication, and so you need to use kerberos (clients and our server). This means setting up SRV records, keytab, etc, etc. It's possible, but you have to know what you're doing, and results may be mediocre for Windows clients (because they expected to be joined to an AD domain). If you need SMB access it's better to use AD (Samba or Windows).

If your FreeIPA domain already has a cross-realm trust with an AD domain, it's generally better to just join AD on TrueNAS, configure idmap backend for the FreeIPA domain, and then access that way (it should allow your Linux FreeIPA-joined clients to kinit and access server over SMB). That said, this carries with it the general idea that your FreeIPA users are not AD users and vice-versa (they are two distinct realms). This translates into them having separate ID spaces on the TrueNAS server.
 
Last edited:

DannyB

Cadet
Joined
Apr 20, 2022
Messages
8
For what it's worth, i know this is an old thread, but in case someone later tries to figure this out.

It's possible to get this to work on TrueNAS scale, but it's a pill, and required a lot of debugging of winbindd to figure out what was going on.

1. The default LDAP configuration it makes is wrong if you use SSL. It still tries to use starttls. Easiest way around this is to set everything to use start tls rather than SSL.
2. Samba now requires write access to one of the main DN's. So you need to have it use a directory manager user so it can verify the ID pool.
3. ipa-adtrust-install needs to be run on the servers.
4. cifs keytab needs to be created with a machine password (see https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html)
5. place cifs, keytab in /root/samba-keytab
6. SID needs to be set right (follow the guide above)
7. Aux parameters in truenas need to be set to enable the keytab/etc
Use:
dedicated keytab file = FILE:/root/samba-keytab/samba.keytab
kerberos method = dedicated keytab
server role = member server
realm = IPA REALM NAME (IE SERVERS.DBERLIN.ORG or whatever)

Note that your aux parameters will get overwritten in the registry if you touch the directory services config. So if you do that, you need to go back to the service config and re-save it so it re-adds the aux parameters to the registry.

You can use samba-regedit to verify your parameters are there (HKLM\Software\Samba\smbconf)

Lastly, you need to set the machine password.
The guide has directions. The db is in /var/db/system/samba rather than /var/lib/samba.

Once you do all that, restart the winbind and smb servers, and authentication using ipa users should work.


Honestly, after making it work, i think i would just move to AD.
 

leoconforti

Cadet
Joined
Nov 9, 2022
Messages
2
For what it's worth, i know this is an old thread, but in case someone later tries to figure this out.

It's possible to get this to work on TrueNAS scale, but it's a pill, and required a lot of debugging of winbindd to figure out what was going on.

1. The default LDAP configuration it makes is wrong if you use SSL. It still tries to use starttls. Easiest way around this is to set everything to use start tls rather than SSL.
2. Samba now requires write access to one of the main DN's. So you need to have it use a directory manager user so it can verify the ID pool.
3. ipa-adtrust-install needs to be run on the servers.
4. cifs keytab needs to be created with a machine password (see https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html)
5. place cifs, keytab in /root/samba-keytab
6. SID needs to be set right (follow the guide above)
7. Aux parameters in truenas need to be set to enable the keytab/etc
Use:
dedicated keytab file = FILE:/root/samba-keytab/samba.keytab
kerberos method = dedicated keytab
server role = member server
realm = IPA REALM NAME (IE SERVERS.DBERLIN.ORG or whatever)

Note that your aux parameters will get overwritten in the registry if you touch the directory services config. So if you do that, you need to go back to the service config and re-save it so it re-adds the aux parameters to the registry.

You can use samba-regedit to verify your parameters are there (HKLM\Software\Samba\smbconf)

Lastly, you need to set the machine password.
The guide has directions. The db is in /var/db/system/samba rather than /var/lib/samba.

Once you do all that, restart the winbind and smb servers, and authentication using ipa users should work.


Honestly, after making it work, i think i would just move to AD.

I tried this, and a lot of other things too, but ultimately nothing works for me. Trying to use smbclient -k from a different machine joined to freeipa on the network, these are the contents of tail -f /var/log/samba4/log.smbd when running the smbclient command from

[2022/11/09 22:24:59] ../../source3/lib/tallocmsg.c:84(register_msg_pool_usage) Registered MSG_REQ_POOL_USAGE [2022/11/09 22:24:59] ../../lib/krb5_wrap/krb5_samba.c:1541(smb_krb5_kt_open) smb_krb5_kt_open: ERROR: Invalid keytab name: FILE:/etc/samba/samba.keytab [2022/11/09 22:24:59] ../../source3/librpc/crypto/gse_krb5.c:500(fill_mem_keytab_from_dedicated_keytab) smb_krb5_kt_open of FILE:/etc/samba/samba.keytab failed (Key table name malformed) [2022/11/09 22:24:59] ../../source3/librpc/crypto/gse_krb5.c:594(gse_krb5_get_server_keytab) ../../source3/librpc/crypto/gse_krb5.c:595: Error! Unable to set mem keytab - -1765328205 [2022/11/09 22:24:59] ../../auth/gensec/gensec_start.c:861(gensec_start_mech) Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR

what stands out to me is the second line, ERROR: Invalid keytab name. Google searching this verbatim has almost 0 results, the most helpful result was this file form the samba repository on github. It does a check for if the file starts with the string "/", "FILE:/", or "WRFILE:/". I have tried all tree of these variations and yet they all don't work. I have tried putting the filename in quotes, but still doesn't work. Does anyone have any advice on what I am doing wrong?
 

leoconforti

Cadet
Joined
Nov 9, 2022
Messages
2
Solved this problem but another one has come up. Inspecting the error message very closely reveals that the printed kerberos keytab file name is
FILE:/etc/samba/samba.keytab
You can only see it if you highlight the error message with your mouse, but there are two spaces at the beginning for some reason. One space comes from the debug message, and the other space is the space after the equal sign. Changing
dedicated keytab file = FILE:/root/samba-keytab/samba.keytab
to
dedicated keytab file =FILE:/root/samba-keytab/samba.keytab
solves the issue. Now though, when trying to use smbclient, the following error comes up:

Cannot contact any KDC for requested realm, session setup failed: NT_STATUS_NO_LOGON_SERVERS
and there is nothing in the /var/log/samba4/log.smbd log anymore.
 

mueslo

Cadet
Joined
Apr 21, 2015
Messages
5
7. Aux parameters in truenas need to be set to enable the keytab/etc
Use:
dedicated keytab file = FILE:/root/samba-keytab/samba.keytab
kerberos method = dedicated keytab
server role = member server
realm = IPA REALM NAME (IE SERVERS.DBERLIN.ORG or whatever)

Note that your aux parameters will get overwritten in the registry if you touch the directory services config. So if you do that, you need to go back to the service config and re-save it so it re-adds the aux parameters to the registry.
^^To clarify for others, this goes in the samba service auxiliary parameters

Solved this problem but another one has come up. Inspecting the error message very closely reveals that the printed kerberos keytab file name is

You can only see it if you highlight the error message with your mouse, but there are two spaces at the beginning for some reason. One space comes from the debug message, and the other space is the space after the equal sign. Changing
dedicated keytab file = FILE:/root/samba-keytab/samba.keytab
to
dedicated keytab file =FILE:/root/samba-keytab/samba.keytab
solves the issue. Now though, when trying to use smbclient, the following error comes up:

Cannot contact any KDC for requested realm, session setup failed: NT_STATUS_NO_LOGON_SERVERS
and there is nothing in the /var/log/samba4/log.smbd log anymore.
I had the same issue. After checking that all my DNS was setup properly (e.g. SRV records etc. - check ipa dns-update-system-records --dry-run and compare to local DNS responses), which they were, I realized my FreeIPA host's firewall was blocking the traffic.

I had to firewall-cmd --permanent --add-service samba-dc on my FreeIPA host.
 

mueslo

Cadet
Joined
Apr 21, 2015
Messages
5
The next issue afterwards is idmap. When connecting to Samba, the SID of your FreeIPA user (ipaNTSecurityIdentifier in LDAP) is sent to idmap to convert to a POSIX UID and GID. There are various backends that do this. The TDB backend just sequentially gives out new IDs, which is not nice for obvious reasons. The RID backend uses the RID part of your SID as the RID offset to your configured ID range.

e.g.
IPA uidNumber: yyyyyyyyy0000000012 -> RID 12
SID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1012 -> RID 1012

However, the issue here is that the native IPA RID range starts at 0, whereas the SID RIDs start at 1000. If we then set the RID backend id range to the same as for IPA, this will cause a problem meaning that Samba authentication will fail by default, since the mapped SID would then end up being yyyyyyyyy0000001012, for which there is no user (or a different user!!). If you login via SSH (with ldap), you will be yyyyyyyyy0000000012.

I do not have a solution so far, only a very dirty workaround. I simply subtracted 1000 from my configured Samba range limits. As far as I know is in *no way* guaranteed that the SID/UID offset should always be 1000 so this is dangerous and I don't recommend anyone else to do this. However, I ran out of patience for now...

Directly using AD/winbind in nsswitch does solve the mismatch between SSH logins and Samba logins, it does not however solve the main problem, since I would like IDs on FreeNAS to correspond to to uidNumbers from FreeIPA LDAP for e.g. seamless NFS mounts.

I'd be grateful if anyone has some tips on how to get idmap to work more nicely and map to the same user you get when logging in via SSH from pam_ldap.so
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,545
The next issue afterwards is idmap. When connecting to Samba, the SID of your FreeIPA user (ipaNTSecurityIdentifier in LDAP) is sent to idmap to convert to a POSIX UID and GID. There are various backends that do this. The TDB backend just sequentially gives out new IDs, which is not nice for obvious reasons. The RID backend uses the RID part of your SID as the RID offset to your configured ID range.

e.g.
IPA uidNumber: yyyyyyyyy0000000012 -> RID 12
SID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1012 -> RID 1012

However, the issue here is that the native IPA RID range starts at 0, whereas the SID RIDs start at 1000. If we then set the RID backend id range to the same as for IPA, this will cause a problem meaning that Samba authentication will fail by default, since the mapped SID would then end up being yyyyyyyyy0000001012, for which there is no user (or a different user!!). If you login via SSH (with ldap), you will be yyyyyyyyy0000000012.

I do not have a solution so far, only a very dirty workaround. I simply subtracted 1000 from my configured Samba range limits. As far as I know is in *no way* guaranteed that the SID/UID offset should always be 1000 so this is dangerous and I don't recommend anyone else to do this. However, I ran out of patience for now...

Directly using AD/winbind in nsswitch does solve the mismatch between SSH logins and Samba logins, it does not however solve the main problem, since I would like IDs on FreeNAS to correspond to to uidNumbers from FreeIPA LDAP for e.g. seamless NFS mounts.

I'd be grateful if anyone has some tips on how to get idmap to work more nicely and map to the same user you get when logging in via SSH from pam_ldap.so
There's an option `sssd_compat` in the idmap rid backend in TrueNAS to auto-detect and set RID range correctly.
 

mueslo

Cadet
Joined
Apr 21, 2015
Messages
5
There's an option `sssd_compat` in the idmap rid backend in TrueNAS to auto-detect and set RID range correctly.
I do not think that this can (even in principle) do what I need it to. I am not using winbind+sssd_idmap anywhere. I am using sssd (via LDAP) on linux servers, sssd does not change uidNumber from LDAP. On FreeNAS I am using LDAP id/auth (without). This gives the same uids/gids as on other linux servers (when logging in via SSH), same as sssd. Everything is fine here so far.

The issue is that Samba on FreeNAS cannot idmap to LDAP uidNumber and instead uses winbind SIDs. Therefore it is in theory impossible to map the SIDs to the right uidNumber.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,545
I do not think that this can (even in principle) do what I need it to. I am not using winbind+sssd_idmap anywhere. I am using sssd (via LDAP) on linux servers, sssd does not change uidNumber from LDAP. On FreeNAS I am using LDAP id/auth (without). This gives the same uids/gids as on other linux servers (when logging in via SSH), same as sssd. Everything is fine here so far.

The issue is that Samba on FreeNAS cannot idmap to LDAP uidNumber and instead uses winbind SIDs. Therefore it is in theory impossible to map the SIDs to the right uidNumber.
Is SSSD in your case bound to AD or FreeIPA?
 
Top