Sadly this isn't really an option for us because we have a lot of data on Synology DSM, and unless Synology decides to implement SSSD or freeipa-client, which I find very unlikely, our task remains authenticating the DSM SMB mounts via LDAP.  That is, we need our Synology devices to be accessible for the users with the user/password credentials set on FreeIPA.

I don't know any way of doing that other than the schemes shown in guides like the above (Opolka) or Frederik Lindenaar who goes at it in more detail https://frederik.lindenaar.nl/2019/07/14/integrating-synology-ds-with-freeipa.html



Am Mi., 7. Feb. 2024 um 19:38 Uhr schrieb Alexander Bokovoy <abokovoy@redhat.com>:
On Пан, 05 лют 2024, Melissa Ferreira da Silva Boiko wrote:
>Thanks for the suggestions so far!
>
>I'm documenting this on this thread because I found out why the previous
>system had the custom sambaSamAccount attributes: They seem to be necessary
>to authenticate SMB shares when FreeIPA is the LDAP backend to a Synology
>NAS.  If I try to set LDAP authentication now, I get this error on Synology
>DSM:
>
>> Issue Details: The LDAP server does not support Samba schema.
>> ...
>> Recommended action: Enable CIFS plain text password authentication.  [and
>if you do], this DSM cannot be the remote mount target of CIFS.
>
>Some past threads on freeipa-users (mostly for TrueNAS) suggest that the
>Samba schema attributes are deprecated in favour of something using
>Kerberos, but I do not get that option in Synology at all.
>
>I believe the previous sysadmins of our shop must have followed this guide
>by Markus Opolka, or a similar HOWTO:
>https://blog.cubieserver.de/2018/synology-nas-samba-nfs-and-kerberos-with-freeipa-ldap/

Sadly, this blog is making a lot of wrong suggestions. A particularly
bad one is about a structure of sambaSID value as SIDs have very
specific structure and breaking that would actually break Samba as well.
S-1-5-21- is a prefix for domain SIDs. This means that values after
S-1-5-21- prefix would need to be the domain SID triplet and a relative
identifier, RID:

    S-1-5-21-d1-d2-d3-RID.

Samba expects this.

Another part is that you don't really need that all if you are running
SSSD. In such case you can use idmap_sss module to supply user/groups to
Samba together with SIDs directly:
https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html

The whole configuration is handled by ipa-client-samba tool on IPA
client (part of freeipa-client-samba package in Fedora).

Sadly, TrueNAS folks also didn't go this way and instead added LDAP
mapping support in their recent beta1 release. This also will not give
you proper SIDs exposed as Samba's pdb_ldap driver does not have ability
to change LDAP attribute mapping and hardcodes the sambaSID/etc
attribute names, making it not compatible with FreeIPA schema.

You'd end up making separate set of FreeIPA-native and Samba-expected
attributes this way. It is a management nightmare because you certainly
want to stick to IPA-generated SIDs as they will be part of the Kerberos
tickets issued by IPA KDC and will be properly accepted by Samba. Using
ipa-client-samba tool and its configuration is best as it seamlessly
connects both Samba and FreeIPA. But both Synology and TrueNAS ignore
it, unfortunately.

>
>That would explain why I couldn't create users with the Web interface in my
>new FreeIPA (4.11) instance; this guide necessitates manual setting of the
>Samba attributes via command-line `ipa user-add` flags.
>
>However, it is then a mystery to me why user account creation worked via
>Web interface in the old (4.5) instance.

It worked due to you adding those attributes and object classes into the
list of user attributes/object classes in IPA configuration.

>I'm not sure how to proceed here since CIFS mounting is one of our users'
>primary uses of LDAP in the first place.  Maybe I'll recreate the Samba
>attributes after all, try to restore the previous values from backups, and
>document properly how to create users with the command-line options.

For a normal IPA-enrolled client Samba integration is trivial:

  - install freeipa-client-samba (ipa-client-samba in RHEL)
  - run ipa-client-samba tool
  - check generated /etc/samba/smb.conf, adjust
  - enable smb and winbind systemd services and activate them
  - done.


>
>[]s
>
>Am Mo., 29. Jan. 2024 um 14:52 Uhr schrieb Alexander Bokovoy <
>abokovoy@redhat.com>:
>
>> On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users
>> wrote:
>> >Seems like it has "ipaUserObjectClasses: sambasamaccount" which I see
>> >mentioned in very old threads about Samba support only.  Here's the
>> >full config:
>>
>> Thanks. You can remove sambaSamAccount by running
>>
>> $ ipa config-mod --delattr=ipaUserObjectClasses=sambaSamAccount
>>
>> Same applies to shadowAccount which we don't use by default either.
>>
>> >
>> >```
>> >  dn: cn=ipaConfig,cn=etc,dc=example,dc=local
>> >  ipamaxusernamelength: 32
>> >  ipahomesrootdir: /home
>> >  ipadefaultloginshell: /bin/bash
>> >  ipadefaultprimarygroup: ipausers
>> >  ipadefaultemaildomain: example.com
>> >  ipasearchtimelimit: 2
>> >  ipasearchrecordslimit: 100
>> >  ipausersearchfields: uid,givenname,sn,telephonenumber,ou,title
>> >  ipagroupsearchfields: cn,description
>> >  ipamigrationenabled: FALSE
>> >  ipacertificatesubjectbase: O=EXAMPLE.LOCAL
>> >  ipapwdexpadvnotify: 4
>> >  ipaconfigstring: AllowNThash
>> >  ipaconfigstring: KDC:Disable Last Success
>> >  ipaselinuxusermaporder:
>> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>> >  ipaselinuxusermapdefault: unconfined_u:s0-s0:c0.c1023
>> >  ipakrbauthzdata: MS-PAC
>> >  ipakrbauthzdata: nfs:NONE
>> >  ipauserauthtype: disabled
>> >  ipauserauthtype: password
>> >  cn: ipaConfig
>> >  ipaGroupObjectClasses: top
>> >  ipaGroupObjectClasses: groupofnames
>> >  ipaGroupObjectClasses: nestedgroup
>> >  ipaGroupObjectClasses: ipausergroup
>> >  ipaGroupObjectClasses: ipaobject
>> >  ipaMaxHostnameLength: 64
>> >  ipaUserObjectClasses: top
>> >  ipaUserObjectClasses: person
>> >  ipaUserObjectClasses: organizationalperson
>> >  ipaUserObjectClasses: inetorgperson
>> >  ipaUserObjectClasses: inetuser
>> >  ipaUserObjectClasses: posixaccount
>> >  ipaUserObjectClasses: krbprincipalaux
>> >  ipaUserObjectClasses: krbticketpolicyaux
>> >  ipaUserObjectClasses: ipaobject
>> >  ipaUserObjectClasses: ipasshuser
>> >  ipaUserObjectClasses: sambasamaccount
>> >  ipaUserObjectClasses: shadowAccount
>> >  objectClass: nsContainer
>> >  objectClass: top
>> >  objectClass: ipaGuiConfig
>> >  objectClass: ipaConfigObject
>> >  objectClass: ipaUserAuthTypeClass
>> >  objectClass: ipaNameResolutionData
>> >```
>> >
>> >Thanks!
>> >--
>> >_______________________________________________
>> >FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> >To unsubscribe send an email to
>> freeipa-users-leave@lists.fedorahosted.org
>> >Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> >List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>> >Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>>
>>
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
>>
>>




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland