Hi,
I'm trying to upgrade an ancient master replica (the CA master) running FreeIPA 4.5 on CentOS 7.4. Upgrading the freeipa packages in-place (in a cloned VM) caused numerous problems so I'm trying to create a new master replica on a fresh Fedora 39, using the "Migrating to different platform or OS" procedure described on https://www.freeipa.org/page/Howto/Migration
At first sight the new replica appears to work, but user creation fails, both on the web and command-line, with:
ipa user-add --first=Testy --last=McTestface teste123 ipa: ERROR: missing attribute "sambaSID" required by object class "sambaSamAccount"
Web searches seem to suggest this is due to a missing DNA plugin that should autogenerate the sambaSIDs, but I failed to find a guide on how to enable that plugin with current IPA (4.11). Should it be enabled automatically?
Unless it's used for something internal to IPA I don't think we actually are even using AD integration or SMB shares, so removing Samba support altogether would also be an option, but I don't know what's the safe way of doing that to the schema either.
Thanks for your help!
On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:
Hi,
I'm trying to upgrade an ancient master replica (the CA master) running FreeIPA 4.5 on CentOS 7.4. Upgrading the freeipa packages in-place (in a cloned VM) caused numerous problems so I'm trying to create a new master replica on a fresh Fedora 39, using the "Migrating to different platform or OS" procedure described on https://www.freeipa.org/page/Howto/Migration
At first sight the new replica appears to work, but user creation fails, both on the web and command-line, with:
ipa user-add --first=Testy --last=McTestface teste123 ipa: ERROR: missing attribute "sambaSID" required by object class "sambaSamAccount"
Web searches seem to suggest this is due to a missing DNA plugin that should autogenerate the sambaSIDs, but I failed to find a guide on how to enable that plugin with current IPA (4.11). Should it be enabled automatically?
Unless it's used for something internal to IPA I don't think we actually are even using AD integration or SMB shares, so removing Samba support altogether would also be an option, but I don't know what's the safe way of doing that to the schema either.
Looks like your old deployment had been using custom object classes and attributes. FreeIPA does not use sambaSID and sambaSamAccount at all. These attributes and object classes are part of IPA setup but they aren't used.
FreeIPA uses different set of attributes/object classes for storing SID-related information for more than a decade. That information is now mandatory to prevent a number of impersonation attacks that could be possible in a Kerberized environment without MS-PAC structures in Kerberos tickets.
Since 'sambaSID' is not used by IPA, it is probably something that your deployment has been using to add by default. Can you show output of
$ ipa config-show --all --raw
?
Seems like it has "ipaUserObjectClasses: sambasamaccount" which I see mentioned in very old threads about Samba support only. Here's the full config:
``` 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!
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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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-fr...
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.
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.
[]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.fedorahoste...
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
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-fr...
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...
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.fedorahoste...
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
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-freeip...
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-fr...
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...
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.fedorahoste...
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
freeipa-users@lists.fedorahosted.org