[SSSD-users] SSSD InfoPipe responder cache and attributes
SSSD team, Hello! I'm a bit perplexed on how to validate and test data read by the Dbus/IFP responder. I'd like to better understand the cache aspects and how to validate that non-default whitelisted attributes are in fact exposed. I'm using the AD provider against a 2012 R2 back end. [sssd] config_file_version = 2 services = nss,pam,pac,ifp domains = dvc.darkvixen.com [nss] reconnection_retries = 3 filter_users = root,bin,daemon,games,gdm,lp,nobody,openslp,rpc,statd filter_groups = root,bin,daemon,sys,disk,lp,audio,floppy,cdrom,video,games [pam] [pac] [ifp] allowed_uids = root,wwwrun,sssd user_attributes = +mail,+department,+telephoneNumber,-gecos [domain/dvc.darkvixen.com] id_provider = ad enumerate = false cache_credentials = true case_sensitive = false override_homedir = /home/%u override_shell = /bin/bash override_gid = 1727401607 ldap_user_extra_attrs = mail,department,telephoneNumber Output from sssctl: # sssctl user-show msteele Name: msteele Cache entry creation date: 01/08/21 10:14:35 Cache entry last update time: 01/08/21 14:04:18 Cache entry expiration time: 01/08/21 15:34:18 Initgroups expiration time: 01/08/21 15:34:18 Cached in InfoPipe: No # sssctl user-checks msteele user: msteele action: acct service: system-auth SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401607 - gecos: Ming Steele - home directory: /home/msteele - shell: /bin/bash SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: - homeDirectory: /home/msteele - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env - Should the attributes in fact be cached and displayed? Packages installed: # rpm -qa | grep sss python-sssdconfig-1.16.5-10.el7_9.5.noarch sssd-client-1.16.5-10.el7_9.5.armv7hl libsss_autofs-1.16.5-10.el7_9.5.armv7hl sssd-common-1.16.5-10.el7_9.5.armv7hl libsss_simpleifp-1.16.5-10.el7_9.5.armv7hl sssd-ad-1.16.5-10.el7_9.5.armv7hl libsss_idmap-1.16.5-10.el7_9.5.armv7hl libsss_certmap-1.16.5-10.el7_9.5.armv7hl sssd-libwbclient-1.16.5-10.el7_9.5.armv7hl libsss_sudo-1.16.5-10.el7_9.5.armv7hl sssd-polkit-rules-1.16.5-10.el7_9.5.armv7hl sssd-dbus-1.16.5-10.el7_9.5.armv7hl sssd-common-pac-1.16.5-10.el7_9.5.armv7hl sssd-tools-1.16.5-10.el7_9.5.armv7hl sssd-ldap-1.16.5-10.el7_9.5.armv7hl libsss_nss_idmap-1.16.5-10.el7_9.5.armv7hl sssd-krb5-common-1.16.5-10.el7_9.5.armv7hl python-sss-1.16.5-10.el7_9.5.armv7hl sssd-krb5-1.16.5-10.el7_9.5.armv7hl -- lawrence ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: I'm being a toad. SSSD on Centos authenticating to LDAPS configured AD domain
Tory, Some of the directives specified seem unnecessary. For example since you're using a ldaps URI there's no need to implement TLS directives, and since the LDAP backend is AD many of the attribute mappings are likely unnecessary as well unless there's something we don't understand at play. Perhaps simplify the config first. I would try the following and test. # ldap_id_use_start_tls = true # ldap_service_port = 636 ldap_tls_reqcert = allow ldap_force_upper_case_realm = true ldap_uri = ldaps://aadds.com ldap_search_base = dc=aadds,dc=com # ldap_user_object_class = posixAccount ldap_default_bind_dn = aadds\sssd ldap_default_authtok_type = password ldap_default_authtok = somearbitrarycrap ldap_tls_cacertdir = /etc/openldap/cacerts # Unix to AD attribute mapping ldap_schema = ad # ldap_schema = rfc2307 # ldap_user_object_class = person # ldap_group_object_class = group # ldap_user_home_directory = unixHomeDirectory # ldap_user_modify_timestamp = whenChanged # ldap_user_principal = userPrincipalName # ldap_user_name = sAMAccountName # ldap_user_gecos = displayName # ldap_user_uid_number = uidNumber # ldap_user_gid_number = gidNumber # ldap_user_shell = loginShell # ldap_group_name = uniqueMember -- lawrence On Thu, Oct 22, 2020, 2:54 AM Tory M Blue wrote: > I've got SSSD working local via AD for unix account authentication, > however we are joining a new mother ship and we are not on their LAN and > thus don't have access to their AD network. > > They setup an LDAPS configuration and while I can query it via ldapsearch, > I can't get sssd to find anything. getent nor id return anything, but I > see the requests in the sssd_domain.log. I'm sure I'm tripping up trying to > refactor my AD config to work in the new LDAPs environment. > > I understand my ldapsearch is doing a full blown query list and obviously > if I give it a filter of my user for example, I get all my data (sssd > doesn't need all that data but i need something). > > I've spent a week banging my head and searching and trying different > examples and really failing :) > > So any assistance would be appreciated. I've tried the search, trial and > error, read and figured I've exhausted my understanding and exhausted my > attempts at copying others configurations and now I'm just running in > circles. > > Thanks in advance. > > So basic data: > > CentOS 7 > sssd 1.16.4 > LDAPS endpoint on a windows AD domain. > > sssd.conf > > [domain/LDAP] > > # Return debug level to 0 once working > debug_level = 9 > > default_domain_suffix = aads.com > enumerate = false > cache_credentials = false > id_provider = ldap > auth_provider = ldap > #access_provider = ldap > sudo_provider = ldap > chpass_provider = ldap > > # timing config > entry_cache_timeout = 10 > # entry_cache_nowait_timeout = 10 > # entry_cache_nowait_percentage = 10 > > #use_fully_qualified_names = true > ldap_id_use_start_tls = true > ldap_service_port = 636 > ldap_tls_reqcert = allow > ldap_force_upper_case_realm = true > ldap_uri = ldaps://aadds.com > ldap_search_base = dc=aadds,dc=com > ldap_user_object_class = posixAccount > ldap_default_bind_dn = aadds\sssd > ldap_default_authtok_type = password > ldap_default_authtok = somearbitrarycrap > ldap_tls_cacertdir = /etc/openldap/cacerts > > > # Unix to AD attribute mapping > ldap_schema = rfc2307bis > #ldap_schema = rfc2307 > ldap_user_object_class = person > ldap_group_object_class = group > ldap_user_home_directory = unixHomeDirectory > > ldap_user_modify_timestamp = whenChanged > ldap_user_principal = userPrincipalName > ldap_user_name = sAMAccountName > ldap_user_gecos = displayName > ldap_user_uid_number = uidNumber > ldap_user_gid_number = gidNumber > ldap_user_shell = loginShell > ldap_group_name = uniqueMember > > Some data has been secured. > > #> ldapsearch -v -x -D AADDS\\sssd -b "dc=aadds,dc=com" -H ldaps:// > aadds.com -W "(cn=tory blue)" > ldap_initialize( ldaps://aadds.com:636/??base ) > Enter LDAP Password: > filter: (cn=tory blue) > requesting: All userApplication attributes > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (cn=tory blue) > # requesting: ALL > # > > # Tory Blue, AA Users, aadds.com > > > #> id tory.b...@aads.com > #> id tory.blue > #> > > sssd debug: > > Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sbus_get_sender_id_send] > (0x2000): Not a sysbus message, quit > (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_get_account_info_handler] > (0x0200): Got request for [0x1][BE_REQ_USER][name=tory.b...@aadds.com] > (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): DP > Request [Account #8]: New request. Flags [0x0001]. > (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): > Number of active DP request: 1 > (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sss_domain_get_state] > (0x1000): Domain LDAP is Active > (Wed Oct 21 23:37:42 2020) [sssd[be[LDAP]]] [sdap_id_op_connect_step] > (0x4000): reusing cached connection > (Wed Oct 21 23:37:42
[SSSD-users] Re: Are sssd's AD SASL bindings signed?
I believe it will still connect to the LDAP and GC ports, just the protocol changes. To my knowledge going with the AD provider might help but you're using LDAP for a reason instead I assume. Thinking about it though LDAP and CLDAP calls will still connect to those ports. -- lawrence On Wed, Sep 2, 2020 at 3:17 PM Spike White wrote: > Thank you. > > What cybersecurity is reporting off of is a particular event number on its > AD controllers. which is showing a connection to a LDAP port. > > Is there another (better) event that it should be looking for instead? > I.e., it should be flagging a simple binding only to an LDAP port. > > We have a MS consultant, but they're not sssd-knowledgeable. > > Spike > > On Wed, Sep 2, 2020 at 2:02 PM James Ralston wrote: > >> On Wed, Sep 2, 2020 at 1:46 PM Spike White >> wrote: >> >> > I apologize if this has been covered already. But this was just >> > brought up by our cybersecurity team. They plan to disable >> > "deprecated protocols". By that, they mean simple LDAP binding to >> > AD's LDAP port. Because of passing content in clear text. >> >> This was covered already, yes. Here’s a summary: >> >> >> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/3AJ2VQ6ORP52QNGDSGHYQLY45ZKEUBOJ/ >> >> For the full discussion, search the list archives for these threads: >> >> Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. >> Subject: [SSSD-users] SSSD and the forthcoming Active Directory >> LDAPocalypse >> >> > But cybersecurity is asking -- are the question "are these >> > connections signed?". I don't know the answer to that. >> >> They are signed, yes, despite the warning that is logged on the DC. >> You can verify this with a packet trace. See: >> >> >> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/QPAYBNEFOQ7XVS6INZA5CPHDCQMYMX3N/ >> >> Using GSS-SPNEGO instead of GSSAPI will silence the warning, but older >> systems (e.g. RHEL6) don’t have GSS-SPNEGO. >> ___ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org >> > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Can enumeration scope for the SSSD be controlled?
Sumit, Thank you. I did not think that was the case obviously. Good to know! I regularly implement group and attribute logic in my search bases :-) . -- lawrence On Fri, Jul 10, 2020 at 11:24 AM Sumit Bose wrote: > On Fri, Jul 10, 2020 at 09:26:46AM -0400, Lawrence Kearney wrote: > > Hello and I hope all is well for everyone and everyone is staying > healthy. > > > > The issue being experienced is actually a bug in another application > being > > resolved by turning enumeration on. Specifically some versions of SLURM. > > > > https://bugs.schedmd.com/show_bug.cgi?id=9318 > > https://bugs.schedmd.com/show_bug.cgi?id=9374 > > > > The job owner on the compute does end up going to "nobody" and turning > > enumeration on does resolve it. Obviously the solution is for the SLURM > > developers to fix the bug. In the interim I wanted to know if there was a > > way to control the scope of enumeration for the SSSD. I'm assuming the > > search base used is irrelevant in the context of enumeration. > > Hi, > > no, ldap_user_search_base and ldap_group_search_base should be > respected. Please have a look at the sssd-ldap man page where it is > explained how you can even add extra filters to the search bases. > > HTH > > bye, > Sumit > > > > > Thank you to everyone as always, > > > > > > -- lawrence > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Can enumeration scope for the SSSD be controlled?
Hello and I hope all is well for everyone and everyone is staying healthy. The issue being experienced is actually a bug in another application being resolved by turning enumeration on. Specifically some versions of SLURM. https://bugs.schedmd.com/show_bug.cgi?id=9318 https://bugs.schedmd.com/show_bug.cgi?id=9374 The job owner on the compute does end up going to "nobody" and turning enumeration on does resolve it. Obviously the solution is for the SLURM developers to fix the bug. In the interim I wanted to know if there was a way to control the scope of enumeration for the SSSD. I'm assuming the search base used is irrelevant in the context of enumeration. Thank you to everyone as always, -- lawrence ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: The SSSD and sIDHistory
Sumit, Thank you for the response and the confirmation. Do you think it be possible to have the daemon reference the sIDHistory attribute for a specific domain SID and "if" it finds it use it for the id-mapping algorithm? This way the previous UID/GID values would be generated for users migrated to new domains as an example. I'm sure there would be other useful results or am I oversimplifying a complex request? Either way I think it would be a useful feature if development is viable. Thanks as always! -- lawrence On Tue, May 19, 2020 at 11:47 AM mohammed irfan < mohammed.irfan2...@gmail.com> wrote: > How to unsubscribe > > On Tue, 19 May 2020, 18:24 Sumit Bose, wrote: > >> On Tue, May 12, 2020 at 06:58:13AM -0400, Lawrence Kearney wrote: >> > Hello! A question, is it possible now, or would there be value in >> > developing the ability, for the daemon to use the siDHistory attribute >> when >> > id-mapping is used for users and groups that are migrated to new >> domains? >> > >> > If I assume correctly, normally there would not be a need for this >> because >> > in direct integration mode id-mapping is constrained by the domain, so >> the >> > object SID is the object SID. However, if you are migrating users to a >> new >> > domain(s) (as the result of organisational changes or upgrades for >> example) >> > it would be very useful if a specific value in the sIDHistory attribute >> > could be referenced for id-mapping so POSIX file systems or other data >> > relationships tied to UID/GID enumerations if they exist were not >> > negatively impacted. >> > >> > And again, if I understand correctly indirect integration modes do not >> > solve this potential issue if the target users reside in domains >> trusted by >> > the IPA domain. >> >> Hi, >> >> you are right, currently the sIDHistory isn't used in direct or indirect >> integration. >> >> I have to admit that I didn't had a close look at the details of >> siDHistory. I know e.g. that the old SIDs are available in the PAC. So >> in theory it might be possible to generate group memberships based on >> the so that you are still a member of the old groups. But it might be >> difficult with the UID because there can be only one. >> >> bye, >> Sumit >> >> > >> > Suggestions or feedback if I misunderstand, and if I do understand >> > correctly is there a possibility of developing a solution for this use >> case? >> > >> > Many thanks as always, >> > >> > >> > -- lawrence >> >> > ___ >> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org >> ___ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org >> > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] The SSSD and sIDHistory
Hello! A question, is it possible now, or would there be value in developing the ability, for the daemon to use the siDHistory attribute when id-mapping is used for users and groups that are migrated to new domains? If I assume correctly, normally there would not be a need for this because in direct integration mode id-mapping is constrained by the domain, so the object SID is the object SID. However, if you are migrating users to a new domain(s) (as the result of organisational changes or upgrades for example) it would be very useful if a specific value in the sIDHistory attribute could be referenced for id-mapping so POSIX file systems or other data relationships tied to UID/GID enumerations if they exist were not negatively impacted. And again, if I understand correctly indirect integration modes do not solve this potential issue if the target users reside in domains trusted by the IPA domain. Suggestions or feedback if I misunderstand, and if I do understand correctly is there a possibility of developing a solution for this use case? Many thanks as always, -- lawrence ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: sssd behavior when most AD controllers blocked?
... perhaps configure an AD site specifically for the DMZ contsining the reachable DCs and reference it in the SSSD config for those hosts ? -- lawrence On Mon, May 11, 2020, 10:20 AM Spike White wrote: > All, > > sssd migration has been working very well for us -- except in the DMZs and > heavily-restricted firewalled network segments. > > For those network segments, the AD site is the same as the equivalent > corporate location. So the typical DNS SRV record lookup reports a wealth > of AD controllers -- most of which are blocked. (not LDAPS traffic > allowed). > > A couple of AD DCs are in the DMZ, etc. > > The old commercial product appears to CLDAP ping every single AD > controller it finds (via DNS SRV lookup). And when one responds, it > queries that DC to get site, preferred DCs, etc. So the commercial product > work, even in the face of most AD DCs blocked. > > adcli join and sssd appears to CLDAP ping only 4-5 AD DCs. If they don't > get a response back, you get an error. If it's lucky enough to CLDAP ping > an unblocked AD DC -- life is good, otherwise not so much. > > Is there an option in adcli join and the sssd startup to CLDAP ping all > DCs?Like the commercial product's behaviour? > > Obviously, I could hard-code the KDCs in /etc/krb5.conf. But there's > multiple downsides to that: >1. AD team switches out DCs w/o notice. >2. Hard to programmatically script out for new builds, as the list of > DCs would vary according to each firewalled-off segment. > > Spike > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] The SSSD and sIDHistory
Hello! A question, is it possible now, or would there be value in developing the ability, for the daemon to use the siDHistory attribute when id-mapping is used for users and groups that are migrated to new domains? If I assume correctly, normally there would not be a need for this because in direct integration mode id-mapping is constrained by the domain, so the object SID is the object SID. However, if you are migrating users to a new domain(s) (as the result of organisational changes or upgrades for example) it would be very useful if a specific value in the sIDHistory attribute could be referenced for id-mapping so POSIX file systems or other data relationships tied to UID/GID enumerations if they exist were not negatively impacted. And again, if I understand correctly indirect integration modes do not solve this potential issue if the target users reside in domains trusted by the IPA domain. Suggestions or feedback if I misunderstand, and if I do understand correctly is there a possibility of developing a solution for this use case? Many thanks as always, -- lawrence ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Migrating from Quest...
... agreed, filtering either by SSSD directive or with search base or even search base + attributes are great options for most use cases. ... but to be clear my suggestion was to use the "files" provider, not the deprecated "local" provider. -- lawrence On Thu, Mar 19, 2020, 8:50 AM Sumit Bose wrote: > On Thu, Mar 19, 2020 at 07:34:18AM -0500, Thomas Harrison wrote: > > What I'm trying to avoid is the creation of the App ID with the wrong UID > > and GID. If I can define it locally ( ie. /etc/passwd ) then the local > > values over-ride the AD values. Also trying to do it without POSIX > > attributes because InfoSec has been slow there. > > I believe I can stop SSSD and add the local ID but ran across the > > sss_useradd command along w other sss_* commands. I need to setup a > > [domain/local] stanza in sssd.conf though. > > Hi, > > please don't do this, the local provider is deprecated. I think it would > be better to filter out the unwanted users from AD. You can do this by > tuning the 'ldap_user_search_base' option (see man sssd-ldap for > details). If dedicated OUs are used in AD to store the "real" users and > the App IDs and other unwanted users you can just list the "wanted" OUs > with the option. If they are mixed in a single or multiple OUs you have > to look for an LDAP attribute which can be used to separate them and use > this in a filter. > > HTH > > bye, > Sumit > > > Us, Im unsure of removing /var/lib/sss/db/* and mc/* would wioe out any > > settings if not defined in /etc/passwd. > > > > On Thu, Mar 19, 2020, 06:40 Sumit Bose wrote: > > > > > On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote: > > > > Certainly at first. Phase 1 is to replace Quest for the cost saving > with > > > > as little change to the overall function as possible. Since pbly > mapfile > > > > users authenticate via AD in Quest, only those IDs are being "realm > > > > permitted" at this time. > > > > > > Hi, > > > > > > ok, so assuming user joe is allowed and expected to log in. What you > > > want to avoid is that user joe calls 'su - App_ID', enters the App_ID > > > password stored in AD and then can run commands as App_ID user? > > > > > > bye, > > > Sumit > > > > > > > > > > > On Thu, Mar 19, 2020, 04:53 Sumit Bose wrote: > > > > > > > > > On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote: > > > > > > Wow Spike! You're faster and better than the support we pay > for! 8) > > > > > > > > > > > > Summary. > > > > > > RHEL 6 and 7. Plus AWS. > > > > > > I already wrote the scripts to convert user IDs to match. ( our > > > > > > /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX > > > > > > We are limiting for the most part, the above conversion to only > > > entries > > > > > in > > > > > > the mapfile. This would exclude App IDs, and Slervice Account > IDs. > > > > > > > > > > Hi, > > > > > > > > > > do I understand correctly that you want that SSSD only handled > "real" > > > > > users from AD and ignores all other accounts like App IDs? > > > > > > > > > > bye, > > > > > Sumit > > > > > > > > > > > > > > > > > Unfortunately, the scenario I've run across, is that I only > limit the > > > > > users > > > > > > and not the Service Accounts to login via *realm permit* and > > > > > inappropriate > > > > > > *su - App_ID" can create it if *getent passwd App_ID* works. > I've > > > tried > > > > > > encouraging that local accounts not have AD names, but that > seems to > > > have > > > > > > fallen on deaf ears. > > > > > > > > > > > > I would like to create these IDs locally with UID:GID etc... > that I > > > > > specify > > > > > > but I'm having issues when SSSD is running. It appears that > setting > > > up a > > > > > > [domain/local] might be the key, along with sss_useradd? But I > would > > > > > like > > > > > > the ID to be created in /etc/passwd as well if possible. We are > > > > > discussing > > > > > > a 2500 Linux Server environment. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Thom > > > > > > > > > > > > On Wed, Mar 18, 2020 at 10:01 PM Spike White < > spikewhit...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > > > Thomas, > > > > > > > > > > > > > > Greetings! I work at a company that is now far along in > > > transitioning > > > > > > > from Quest to sssd. We have a fairly complex AD forest, with > > > multiple > > > > > > > older Linux OS versions we support. > > > > > > > > > > > > > > An excellent place to start is here: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index > > > > > > > > > > > > > > > > > > > > > Focus on the "direct integration" section. > > > > > > > > > > > > > > How simple or difficult your migration journey is -- depends > on two > > > > > things: > > > > > > > 1. How complex your AD forest is (multiple trusted > subdomains? > > > > > > > Extensive use of GC and universal
[SSSD-users] Re: Migrating from Quest...
You could add a SSSD domain using the "files" provider for local account resolution and use files (maybe?) or even LDAP or Kerberos auth for those accounts. I've implemented files+kerberos configurations for similar use cases. Works well. A relatively current version of the daemon is required to use the files provider. Man the sssd.conf for insight to its availability on your systems. Since you're introducing change I would recommend you use remote auth even if you resolve users locally. -- lawrence On Thu, Mar 19, 2020, 8:34 AM Thomas Harrison wrote: > What I'm trying to avoid is the creation of the App ID with the wrong UID > and GID. If I can define it locally ( ie. /etc/passwd ) then the local > values over-ride the AD values. Also trying to do it without POSIX > attributes because InfoSec has been slow there. > I believe I can stop SSSD and add the local ID but ran across the > sss_useradd command along w other sss_* commands. I need to setup a > [domain/local] stanza in sssd.conf though. > Us, Im unsure of removing /var/lib/sss/db/* and mc/* would wioe out any > settings if not defined in /etc/passwd. > > On Thu, Mar 19, 2020, 06:40 Sumit Bose wrote: > >> On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote: >> > Certainly at first. Phase 1 is to replace Quest for the cost saving >> with >> > as little change to the overall function as possible. Since pbly >> mapfile >> > users authenticate via AD in Quest, only those IDs are being "realm >> > permitted" at this time. >> >> Hi, >> >> ok, so assuming user joe is allowed and expected to log in. What you >> want to avoid is that user joe calls 'su - App_ID', enters the App_ID >> password stored in AD and then can run commands as App_ID user? >> >> bye, >> Sumit >> >> > >> > On Thu, Mar 19, 2020, 04:53 Sumit Bose wrote: >> > >> > > On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote: >> > > > Wow Spike! You're faster and better than the support we pay for! 8) >> > > > >> > > > Summary. >> > > > RHEL 6 and 7. Plus AWS. >> > > > I already wrote the scripts to convert user IDs to match. ( our >> > > > /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX >> > > > We are limiting for the most part, the above conversion to only >> entries >> > > in >> > > > the mapfile. This would exclude App IDs, and Slervice Account IDs. >> > > >> > > Hi, >> > > >> > > do I understand correctly that you want that SSSD only handled "real" >> > > users from AD and ignores all other accounts like App IDs? >> > > >> > > bye, >> > > Sumit >> > > >> > > > >> > > > Unfortunately, the scenario I've run across, is that I only limit >> the >> > > users >> > > > and not the Service Accounts to login via *realm permit* and >> > > inappropriate >> > > > *su - App_ID" can create it if *getent passwd App_ID* works. I've >> tried >> > > > encouraging that local accounts not have AD names, but that seems >> to have >> > > > fallen on deaf ears. >> > > > >> > > > I would like to create these IDs locally with UID:GID etc... that I >> > > specify >> > > > but I'm having issues when SSSD is running. It appears that >> setting up a >> > > > [domain/local] might be the key, along with sss_useradd? But I >> would >> > > like >> > > > the ID to be created in /etc/passwd as well if possible. We are >> > > discussing >> > > > a 2500 Linux Server environment. >> > > > >> > > > Thanks! >> > > > >> > > > Thom >> > > > >> > > > On Wed, Mar 18, 2020 at 10:01 PM Spike White < >> spikewhit...@gmail.com> >> > > wrote: >> > > > >> > > > > Thomas, >> > > > > >> > > > > Greetings! I work at a company that is now far along in >> transitioning >> > > > > from Quest to sssd. We have a fairly complex AD forest, with >> multiple >> > > > > older Linux OS versions we support. >> > > > > >> > > > > An excellent place to start is here: >> > > > > >> > > > > >> > > > > >> > > >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index >> > > > > >> > > > > >> > > > > Focus on the "direct integration" section. >> > > > > >> > > > > How simple or difficult your migration journey is -- depends on >> two >> > > things: >> > > > > 1. How complex your AD forest is (multiple trusted subdomains? >> > > > > Extensive use of GC and universal groups? Or a simple flat >> one-domain >> > > > > forest?) >> > > > > 2. How far back in Linux OS versions do you wish to support? >> > > > > >> > > > > If you have a simple flat forest and if you don't have to support >> > > anything >> > > > > earlier than RHEL7, the conversion should be relatively easy. >> > > > > >> > > > > With some effort, you can support cross-domain authentication with >> > > RHEL6 >> > > > > as well. RHEL5? Forget about it! >> > > > > >> > > > > BTW, I'm quite familiar with the VAS commands and what are the >> sssd >> > > > > analogs. (About 99% of what we did in VAS, we have figured out >> how to >> > > do >> > > > > in sssd.) >> > > > > >> > > > >
[SSSD-users] Re: logins fail after socket activated responders implemented.
... that is a good point :-) .
-- lawrence
On Thu, Nov 21, 2019, 7:56 AM Lukas Slebodnik wrote:
> On (21/11/19 09:14), Lawrence Kearney wrote:
> >Lukas et al.,
> >Firstly reverting the ownership of the sssd service and socket files in
> the
> >"/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd and
> >adding the "user = sssd" to the sssd.conf file did resolve the responder
> >issue.This file ownership model was what I thought should be in place, but
> >rhel did not install them consistently this way. I implemented the
> >sssd:root ownerships to resolve some issues with services starting.
> >Interestingly even after changing the ownerships of the same files to
> >sssd:sssd the responder still crashed without the user = sssd directive
> >present in the sssd.conf. I would have thought the daemon on this platform
> >would not require it.
> >
>
> Sorry If I was not clear. I did not suggest to change owner/permissions of
> directories or files
>
> Just to remove "sssd" user and group from systemd service files for sssd
> responders
>
> cp /usr/lib/systemd/system/sssd-pam.service
> /etc/systemd/system/sssd-pam.service
>
> #modify file /etc/systemd/system/sssd-pam.service
> e.g.
> [Unit]
> Description=SSSD PAM Service responder
> Documentation=man:sssd.conf(5)
> After=sssd.service
> BindsTo=sssd.service
> RefuseManualStart=true
>
> [Install]
> Also=sssd-pam.socket sssd-pam-priv.socket
>
> [Service]
> Environment=DEBUG_LOGGER=--logger=files
> EnvironmentFile=-/etc/sysconfig/sssd
> ExecStartPre=-/bin/chown root:root /var/log/sssd/sssd_pam.log
> ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated
> Restart=on-failure
> User=root
> Group=root
> PermissionsStartOnly=true
>
> systemctl daemon-reload
>
>
> >That said, my experience on other platforms is the daemon runs as root, so
> >this is useful to know for additional testing with other distributions, so
> >thank you.
> >
>
> Different distributions build packages with different flags.
>
> >As to the use case discussion, most of my experience and assistance in
> >deployments are direct integration models. Not that I have a technical
> >issue with the indirect approach, but most organisations I encounter
> prefer
> >the reduced complexity of the direct model. As long as it works reliably.
> >There are feature trade offs using this method but most are okay given
> >those choices are communicated.
> >
>
> I am still not sure how socket activated responders would help here.
>
> >That said, when you stand up sssd as a client against a large, mature,
> >complex directory service any thing you can do to reduce the load on the
> >clients and the directory service is a good step. Filtering search results
> >across purposefully configured hosts and reducing load on the client and
> >the directory service are key design components of this proposition.
> >
>
> You still need to provide sssd.conf for each host.
> (and whether there is a line with "services" is a minimal change)
>
>
> >So, I'm curious if the socket based responders can play a meaningful part
> >in optimisation.
> >
> >An addition question that may help me. What are your thoughts on the use
> >case(s) for the socket based responders?
> >
>
> I would say it in this way.
> If distributions though that socket activated responders are tested enough
> hey would enable it by default.
>
> LS
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: logins fail after socket activated responders implemented.
Lukas et al., Firstly reverting the ownership of the sssd service and socket files in the "/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd and adding the "user = sssd" to the sssd.conf file did resolve the responder issue.This file ownership model was what I thought should be in place, but rhel did not install them consistently this way. I implemented the sssd:root ownerships to resolve some issues with services starting. Interestingly even after changing the ownerships of the same files to sssd:sssd the responder still crashed without the user = sssd directive present in the sssd.conf. I would have thought the daemon on this platform would not require it. That said, my experience on other platforms is the daemon runs as root, so this is useful to know for additional testing with other distributions, so thank you. As to the use case discussion, most of my experience and assistance in deployments are direct integration models. Not that I have a technical issue with the indirect approach, but most organisations I encounter prefer the reduced complexity of the direct model. As long as it works reliably. There are feature trade offs using this method but most are okay given those choices are communicated. That said, when you stand up sssd as a client against a large, mature, complex directory service any thing you can do to reduce the load on the clients and the directory service is a good step. Filtering search results across purposefully configured hosts and reducing load on the client and the directory service are key design components of this proposition. So, I'm curious if the socket based responders can play a meaningful part in optimisation. An addition question that may help me. What are your thoughts on the use case(s) for the socket based responders? Thank you! -- lawrence On Thu, Nov 21, 2019 at 5:16 AM Lukas Slebodnik wrote: > On (20/11/19 11:57), Lawrence Kearney wrote: > >Lukas et al., > >Thank you for the suggestion. I'll test that as soon as convenient. I'm > >currently attending SC19 so spinning up labs is something best managed in > >the mornings with coffee :-) . > > > >Curiously I did have to change the ownership of the socket, and a few > >service, unit files to sssd:root to get them to start. I would like to > test > >the daemon to running as an unprivileged user as much as possible. I did > >not consider digging into the files themselves to check configured runtime > >users, I should've. > > > > Using "hybrid" sssd:root is not a good idea. > You should either remove sssd user/group from service files > or run sssd as completely unprivileged user. > > > >As to your question I currently have no real use case for the socket based > >responders other than their potential for system level optimisation in > >large enterprise deployments and kicking the tyres on the SSSD feature set > >to both experiment with it and document the assessment, results, and > >configuration nuances and requirements. > > > > And I an exactly interested in that real use-case :-) > Could you share a little bit more even thought you did not test it? > > Because there might be other solution to the problem you would like to > solve. > > LS > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: logins fail after socket activated responders implemented.
Lukas et al.,
Thank you for the suggestion. I'll test that as soon as convenient. I'm
currently attending SC19 so spinning up labs is something best managed in
the mornings with coffee :-) .
Curiously I did have to change the ownership of the socket, and a few
service, unit files to sssd:root to get them to start. I would like to test
the daemon to running as an unprivileged user as much as possible. I did
not consider digging into the files themselves to check configured runtime
users, I should've.
As to your question I currently have no real use case for the socket based
responders other than their potential for system level optimisation in
large enterprise deployments and kicking the tyres on the SSSD feature set
to both experiment with it and document the assessment, results, and
configuration nuances and requirements.
I often share these results in attempts to help others deploying the daemon
and advocate for its use. Similar to this community :-) .
Thank you again and I'll test asap and report what I find,
-- lawrence
On Wed, Nov 20, 2019 at 11:16 AM Lukas Slebodnik
wrote:
> On (15/11/19 05:23), Lawrence Kearney wrote:
> >SSSD team,
> >Just checking in on this post. Any thoughts why the socket based
> responders
> >would be crashing? Is there any additional info I could provide that would
> >be useful?
> >
> >Thank you as always!
> >
>
> sssd on rhel7 has hardcoded unprivileged user "sssd" for responders.
> And mixing privileged sssd and unprivileged users is not a good idea.
>
> sh# rpm -q sssd-common
> sssd-common-1.16.4-21.el7_7.1.x86_64
>
> sh# systemctl cat sssd-pam.service
> # /usr/lib/systemd/system/sssd-pam.service
> [Unit]
> Description=SSSD PAM Service responder
> Documentation=man:sssd.conf(5)
> After=sssd.service
> BindsTo=sssd.service
> RefuseManualStart=true
>
> [Install]
> Also=sssd-pam.socket sssd-pam-priv.socket
>
> [Service]
> Environment=DEBUG_LOGGER=--logger=files
> EnvironmentFile=-/etc/sysconfig/sssd
> ExecStartPre=-/bin/chown sssd:sssd /var/log/sssd/sssd_pam.log
> ^
> here
> ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated
> Restart=on-failure
> User=sssd
> Group=sssd
> ^
> and here
> PermissionsStartOnly=true
>
>
>
> It works well when sssd is running fully in unprivileged mode.
> "user = sssd" in "sssd" section of sssd.conf
>
> Other option would be to override service files for responder in
> /etc/systmd/system
>
> But I would like to ask why do you want to use socket activated responders
> on
> rhel7?
>
> LS
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: logins fail after socket activated responders implemented.
Sumit, Good to hear back from you and thank you! I had already added the directive to the [pam] responder stanza but the responder doesn't write a log file. Doing a little more testing I can reproduce the responser crash (assumed) using sssctl to check the user status: [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket [root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Authentication service cannot retrieve authentication info PAM Environment: - no env - [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket ● sssd-pam-priv.socket loaded failed failedSSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket How would you recommend moving forward with assessment? -- lawrence On Tue, Nov 19, 2019 at 1:31 AM Sumit Bose wrote: > On Fri, Nov 15, 2019 at 05:23:35AM -0500, Lawrence Kearney wrote: > > SSSD team, > > Just checking in on this post. Any thoughts why the socket based > responders > > would be crashing? Is there any additional info I could provide that > would > > be useful? > > Hi, > > can you try to add 'debug_level = 9' to the [pam] section of sssd.conf? > With this the PAM responder should at least add some log messages if > systemd tries to start it. > > bye, > Sumit > > > > > Thank you as always! > > > > > > -- lawrence > > > > On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney > > wrote: > > > > > ... I did notice this after a login attempt: > > > > > > [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- > > > > > > sssd-autofs.socket loaded active listening SSSD AutoFS > Service > > > responder socket > > > sssd-kcm.socket loaded active listening SSSD Kerberos > Cache > > > Manager responder socket > > > sssd-nss.socket loaded active running SSSD NSS Service > > > responder socket > > > sssd-pac.socket loaded active listening SSSD PAC Service > > > responder socket > > > sssd-pam-priv.socket loaded failed failedSSSD PAM Service > > > responder private socket > > > sssd-pam.socket loaded inactive dead SSSD PAM Service > > > responder socket > > > sssd-secrets.socket loaded active listening SSSD Secrets > > > Service responder socket > > > sssd-ssh.socket loaded active listening SSSD SSH Service > > > responder socket > > > sssd-sudo.socket loaded active listening SSSD Sudo > Service > > > responder socket > > > > > > Both PAM responders were running/active/listening prior to the auth > > > attempt following a fresh reboot. > > > > > > /v
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
... admittedly I use triple-s-d myself :-) -- lawrence On Fri, Nov 15, 2019, 8:27 AM James Cassell wrote: > > S-S-S-D here. > > > On Fri, Nov 15, 2019, at 7:57 AM, Pavel Březina wrote: > > We, developers, always use S-S-S-D. I have never heard anyone saying > > Triple-S-D :-) > > > > On 11/15/19 1:49 PM, Jim Burwell wrote: > > > I use both. Triple-S-D is easier. > > > > > > > > > On 2019-11-14 19:20, Spike White wrote: > > >> All, > > >> > > >> S-S-S-D does not seem to roll off the tongue. When I say that, > > >> co-workers think I'm discussing solid-state drives (SSD). When I > call > > >> it triple-S-D, someone invariably corrects me. > > >> > > >> Which is correct? Are both pronunciations correct? > > >> > > >> Spike > > >> > > >> ___ > > >> sssd-users mailing list --sssd-users@lists.fedorahosted.org > > >> To unsubscribe send an email > tosssd-users-le...@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/sssd-users@lists.fedorahosted.org > > > > > > > > > > > > ___ > > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > > To unsubscribe send an email to > sssd-users-le...@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/sssd-users@lists.fedorahosted.org > > > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: logins fail after socket activated responders implemented.
SSSD team, Just checking in on this post. Any thoughts why the socket based responders would be crashing? Is there any additional info I could provide that would be useful? Thank you as always! -- lawrence On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney wrote: > ... I did notice this after a login attempt: > > [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- > > sssd-autofs.socket loaded active listening SSSD AutoFS Service > responder socket > sssd-kcm.socket loaded active listening SSSD Kerberos Cache > Manager responder socket > sssd-nss.socket loaded active running SSSD NSS Service > responder socket > sssd-pac.socket loaded active listening SSSD PAC Service > responder socket > sssd-pam-priv.socket loaded failed failedSSSD PAM Service > responder private socket > sssd-pam.socket loaded inactive dead SSSD PAM Service > responder socket > sssd-secrets.socket loaded active listening SSSD Secrets > Service responder socket > sssd-ssh.socket loaded active listening SSSD SSH Service > responder socket > sssd-sudo.socket loaded active listening SSSD Sudo Service > responder socket > > Both PAM responders were running/active/listening prior to the auth > attempt following a fresh reboot. > > /var/log/secure also contains: > > pam_sss(sshd:auth): Request to sssd failed. Bad address > Failed password for msteele from 192.168.2.1 port 53357 ssh2 > > > -- lawrence > > > On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney > wrote: > >> SSSD team, >> A curious issue after walking through the implementation of the socket >> activated responders. >> >> System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers. >> >> Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) >> worked when specifying the responders in the SSSD.conf file. >> >> [root@darkvixen241 ~]# id msteele >> uid=1727401116(msteele) gid=1727401151(primary_unix_g) >> groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain >> users) >> >> >> [root@darkvixen241 ~]# sssctl user-checks msteele >> user: msteele >> action: acct >> service: system-auth >> >> SSSD nss user lookup result: >> - user name: msteele >> - user id: 1727401116 >> - group id: 1727401151 >> - gecos: Ming Steele >> - home directory: /home/dvc.darkvixen.com/msteele >> - shell: /bin/bash >> >> SSSD InfoPipe user lookup result: >> - name: msteele >> - uidNumber: 1727401116 >> - gidNumber: 1727400513 >> - gecos: Ming Steele >> - homeDirectory: /home/msteele >> - loginShell: /bin/bash >> >> testing pam_acct_mgmt >> >> pam_acct_mgmt: Success >> >> PAM Environment: >> - no env - >> >> >> After implementing the desired socket activated responders I cannot login >> as users via SSH, but can su as them from a root session. User resolution >> and sssctl still work. >> >> [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- >> sssd-autofs.socket loaded active listening SSSD AutoFS >> Service responder socket >> sssd-kcm.socket loaded active listening SSSD Kerberos >> Cache Manager responder socket >> sssd-nss.socket loaded active running SSSD NSS Service >> responder socket >> sssd-pac.socket loaded active listening SSSD PAC Service >> responder socket >> sssd-pam-priv.socket loaded active listening SSSD PAM Service >> responder private socket >> sssd-pam.socket loaded active listening SSSD PAM Service >> responder socket >> sssd-secrets.socket loaded active listening SSSD Secrets >> Service responder socket >> sssd-ssh.socket loaded active listening SSSD SSH Service >> responder socket >> sssd-sudo.socket loaded active listening SSSD Sudo Service >> responder socket >> >> [root@darkvixen241 ~]# id msteele >> uid=1727401116(msteele) gid=1727401151(primary_unix_g) >> groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g
[SSSD-users] Re: logins fail after socket activated responders implemented.
... I did notice this after a login attempt: [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded failed failedSSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket Both PAM responders were running/active/listening prior to the auth attempt following a fresh reboot. /var/log/secure also contains: pam_sss(sshd:auth): Request to sssd failed. Bad address Failed password for msteele from 192.168.2.1 port 53357 ssh2 -- lawrence On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney wrote: > SSSD team, > A curious issue after walking through the implementation of the socket > activated responders. > > System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers. > > Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) > worked when specifying the responders in the SSSD.conf file. > > [root@darkvixen241 ~]# id msteele > uid=1727401116(msteele) gid=1727401151(primary_unix_g) > groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain > users) > > > [root@darkvixen241 ~]# sssctl user-checks msteele > user: msteele > action: acct > service: system-auth > > SSSD nss user lookup result: > - user name: msteele > - user id: 1727401116 > - group id: 1727401151 > - gecos: Ming Steele > - home directory: /home/dvc.darkvixen.com/msteele > - shell: /bin/bash > > SSSD InfoPipe user lookup result: > - name: msteele > - uidNumber: 1727401116 > - gidNumber: 1727400513 > - gecos: Ming Steele > - homeDirectory: /home/msteele > - loginShell: /bin/bash > > testing pam_acct_mgmt > > pam_acct_mgmt: Success > > PAM Environment: > - no env - > > > After implementing the desired socket activated responders I cannot login > as users via SSH, but can su as them from a root session. User resolution > and sssctl still work. > > [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- > sssd-autofs.socket loaded active listening SSSD AutoFS Service > responder socket > sssd-kcm.socket loaded active listening SSSD Kerberos Cache > Manager responder socket > sssd-nss.socket loaded active running SSSD NSS Service > responder socket > sssd-pac.socket loaded active listening SSSD PAC Service > responder socket > sssd-pam-priv.socket loaded active listening SSSD PAM Service > responder private socket > sssd-pam.socket loaded active listening SSSD PAM Service > responder socket > sssd-secrets.socket loaded active listening SSSD Secrets > Service responder socket > sssd-ssh.socket loaded active listening SSSD SSH Service > responder socket > sssd-sudo.socket loaded active listening SSSD Sudo Service > responder socket > > [root@darkvixen241 ~]# id msteele > uid=1727401116(msteele) gid=1727401151(primary_unix_g) > groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain > users) > > [root@darkvixen241 ~]# sssctl user-checks msteele > user: msteele > action: acct > service: system-auth > > SSSD nss user lookup result: > - user name: msteele > - user id: 1727401116 > - group id: 1727401151 > - gecos: Ming Steele > - home directory: /home/dvc.darkvixen.com/msteele > - shell: /bin/bash > > SSSD InfoPipe user lookup result: > - name: msteele > - uidNumber: 1727401116 > - gidNumber: 1727400513 > - gecos: Ming Steele > - homeDirectory: /home/msteele > - loginShell: /bin/bash > > testing pam_acct_mgmt > > pam_acct_mgmt: Authentication service c
[SSSD-users] logins fail after socket activated responders implemented.
SSSD team, A curious issue after walking through the implementation of the socket activated responders. System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers. Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file. [root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users) [root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env - After implementing the desired socket activated responders I cannot login as users via SSH, but can su as them from a root session. User resolution and sssctl still work. [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket [root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users) [root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Authentication service cannot retrieve authentication info PAM Environment: - no env - My sssd.conf is provided below: [sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com [nss] filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody [pam] pam_account_expired_message = "Account expired, please contact help desk." pam_account_locked_message = "Account locked, please contact help desk." pam_verbosity = 3 [pac] [ssh] [autofs] [sudo] [ifp] [domain/dvc.darkvixen.com] id_provider = ad access_provider = ad cache_credentials = true override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151 ad_access_filter = DOM:DVC.DARKVIXEN.COM: (|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com)) Nothing remarkable shows up in the logs after issuing "sssctl debug-level 7" and curiously there are no sssd_pam or sssd_pac log files created. Any assistance would be appreciated, -- lawrence -- Lawrence Kearney w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...
[SSSD-users] Re: Question concerning SSH key attributes
Sumit, I did see the freeIPA slide deck. It had some good info but seemed a bit dated. I'll look into the referenced man file as well. -- lawrence On Mon, Sep 30, 2019, 11:38 AM Sumit Bose wrote: > On Mon, Sep 30, 2019 at 11:25:13AM -0400, Lawrence Kearney wrote: > > A question concerning the following SSSD directives: > > > > ldap_user_ssh_public_key = > > ldap_host_ssh_public_key = > > > > Both default to "sshPublicKey" values, but other than the obvious stated > > use cases (in the directive names and man file entries) I feel I'm > missing > > something concerning the " ldap_host_ssh_public_key" directive. > > > > For example, using the default configuration, the SSSD pulls down the > > public key(s) stored for a user stored in the " sshPublicKey" attribute > > using the "/usr/bin/sss_ssh_authorizedkeys" utility. to facilitate access > > to a predetermined set of hosts. > > > > What is the use case for the " ldap_host_ssh_public_key" directive? Is it > > somehow used to store the public Key for a particular host (and why?) and > > does it have any relationship to the "/usr/bin/sss_ssh_knownhostsproxy" > > utility used to centralise (and distribute?) host keys? > > Yes, please see man sss_ssh_knownhostsproxy for details. Additionally > there are slides describinf this feature at > https://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > . > Although the slides are for FreeIPA the feature itself is not specific > to FreeIPA but can be used with other LDAP servers as well. > > HTH > > bye, > Sumit > > > > > > > Any info would be most useful and as always, thank you! > > > > > > -- lawrence > > > > -- > > Lawrence Kearney > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Question concerning SSH key attributes
A question concerning the following SSSD directives: ldap_user_ssh_public_key = ldap_host_ssh_public_key = Both default to "sshPublicKey" values, but other than the obvious stated use cases (in the directive names and man file entries) I feel I'm missing something concerning the " ldap_host_ssh_public_key" directive. For example, using the default configuration, the SSSD pulls down the public key(s) stored for a user stored in the " sshPublicKey" attribute using the "/usr/bin/sss_ssh_authorizedkeys" utility. to facilitate access to a predetermined set of hosts. What is the use case for the " ldap_host_ssh_public_key" directive? Is it somehow used to store the public Key for a particular host (and why?) and does it have any relationship to the "/usr/bin/sss_ssh_knownhostsproxy" utility used to centralise (and distribute?) host keys? Any info would be most useful and as always, thank you! -- lawrence -- Lawrence Kearney ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: SSSD 1.11.5 AD groups vanish
Given what you're describing I would suspect that enumeration is set to "true" and the cache is being overwhelmed cyclically. Just a thought, -- lawrence On Fri, May 31, 2019 at 2:09 PM Jim Burwell wrote: > Hi, > > I'm experiencing an issue with SSSD 1.11.5 running on Ubuntu 12.04.5 > LTS. It's using the AD provider, pointing to AD servers with POSIX > groups configured (ldap_id_mapping = False). > > The issue I'm experiencing is that all of a user's groups vanishes from > "id" and "groups" after several hours (appears to be 8-12 hours), except > for his/her login group. > > sss_cache -E doesn't fix it > > Restarting SSSD doesn't fix it. > > However, stopping SSSD, removing /var/lib/sss/db/*, and restarting SSSD > does fix it. > > After manually removing the cache files in the DB dir, SSSD will then > see all of a users groups until several hours pass, then, again, all but > his login group will vanish until the files are removed and SSSD > restarted again. > > Is this a known issue, perhaps a bug fixed in some future version? > > BTW, if you're wondering, the SSSD version I'm using is a backport of > 1.11.5 found here in this PPA: > https://launchpad.net/~sssd/+archive/ubuntu/updates > > This is how I'm able to use the AD provider with Ubuntu 12. I know it's > not supported, etc. I'm just looking for any insights or suggestions, > or whether a known bug exists for this version that exhibits this > "vanishing groups" behavior. > > > TIA, > > - Jim > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > -- Lawrence Kearney e: lawrence.kear...@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: ldap domain - queried attributes filter?
Not sure if it helps with the attribute query use case but perhaps incorporating attribute=value directives in the base, or user search base directives: ldap_user_search_base = ou=users,dc=example,dc=com?onelevel?someAttribute=* -- lawrence On Tue, Mar 26, 2019 at 11:45 AM Lukas Slebodnik wrote: > On (26/03/19 14:21), Martin Hansen wrote: > >Hi, > > > >I'm using sssd with LDAP backend / domain. I wonder if there is a way to > influence the attributes which are queried by sssd? Like not just the > mapping but which attributes are ok to be queried and which attributes > should not? I have some cloud servers which are accessing our internal > directory via slapd (proxy). > > > >I have two questions re this: > > > >1. I use "services: nss,pam", so why is sssd querying sudoers information > via the ldap domain like: > > > >ldap filter used by sssd: > >"(&(?objectClass=sudoRole)(|(!(?sudoHost=*))(?sudoHost=ALL)(?sudoHost=ip-xx-xx-xx-xx)(?sudoHost=ip-xx-xx-xx-xx)(?sudoHost=xx.xx.xx.xx)(?sudoHost=xx.xx.xx.xx/xx)?sudoHost=+*)(|(?sudoHost=*\5C*)(?sudoHost=*?*)(?sudoHost=*\2A*)(?sudoHost=*[*]*" > > > > > Previously, there was some heuristic when sudo provider was enable > > man sssd.conf says: >sudo_provider (string) >The SUDO provider used for the domain. Supported SUDO providers >are: > >“ldap” for rules stored in LDAP. See sssd-ldap(5) for more >information on configuring LDAP. > >“ipa” the same as “ldap” but with IPA default settings. > >“ad” the same as “ldap” but with AD default settings. > >“none” disables SUDO explicitly. > >Default: The value of “id_provider” is used if it is set. > >The detailed instructions for configuration of sudo_provider > are in >the manual page sssd-sudo(5). There are many configuration > options >that can be used to adjust the behavior. Please refer to >"ldap_sudo_*" in sssd-ldap(5). > >NOTE: Sudo rules are periodically downloaded in the background >unless the sudo provider is explicitly disabled. Set > sudo_provider >= None to disable all sudo-related activity in SSSD if you do > not >want to use sudo with SSSD at all. > > Just disable sudo provider and such queries will be gone. > > >2. I as well would like to modify the attributes which are queried by > sssd. I would like sssd NOT to query "userPassword" for example. A lot of > other attributes which are queried are not relevant in my environment as > well e.g. the "krb*" attributes. > > > >ldap attributes queried by sssd: > >objectClass uid userPassword uidNumber gidNumber gecos homeDirectory > loginShell krbPrincipalName cn GroupMembership modifyTimestamp > modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning > shadowInactive shadowExpire shadowFlag krbLastPwdChange > krbPasswordExpiration pwdAttribute authorizedService accountExpires > userAccountControl nsAccountLock host rhost loginDisabled > loginExpirationTime loginAllowedTimeMap sshPublicKey userCertificate;binary > mail > > > >Is it possible to influence this behavior somehow, I tried > user_attributes in the domain section as well as in the nss section without > success, e.g. "user_attributes = -userPassword". > > > >any help or clarifying words are appreciated, have a great day > > krb* realted options should be checked just for `auth_provider = krb5` > > You did not share your sssd.conf but you might override some attributes > in sssd.conf (check man page sssd-ldap) > > LS > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > -- Lawrence Kearney e: lawrence.kear...@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Fully qualified prompts shell prompts
A bit of a confusing issue I have not been able to resolve. At times the profile on a system produced the expected user prompt over SSH, and at times a fully qualified one as detailed below. # su - msteele Sometimes I get: # msteele@darkvixen102:~> Sometimes I get: # mste...@darkvixen102.dvc.darkvixen.com:/srv/nfs/home/ dvc.darkvixen.com/msteele> The daemon version is 1.16.1 but it occurs with other versions as well and on other platforms. This one is openSUSE Leap 15. There are no daemon restarts or configuration changes between shell prompt changes. Any thoughts on where to look for a root cause? The fully qualified prompt can be an annoyance. Many thanks as always, -- lawrence ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: Concerning "ldap_idmap_default_domain_sid", "[domain/default]", and "ldap_idmap_default_domain"
... that helps, thanking you! -- lawrence On Wed, Sep 5, 2018 at 12:18 PM Sumit Bose wrote: > On Tue, Sep 04, 2018 at 06:49:15AM -0400, Lawrence Kearney wrote: > > I beleive I understand the use of the the "ldap_idmap_default_domain_sid" > > directive. Most simply the MURMUR algorithm will be disabled and the > domain > > configuration designated as the "default" domain will be assigned to > slice > > [0]. My observation is that the UID-GID for an object becomes > > (ldap_idmap_range_min + ) in this configuration. > > > > The man pages are less clear on why and how specifying which domain is > the > > default in a multi-domain configuration matters. My assumption is that > the > > sole purpose of the "[domain/default]" and "ldap_idmap_default_domain" > > options is to do just that. > > > > "[domain/default]" > > > > - Is the entended use for this domain stanza header? > > - Is is still a valid configuration choice? > > It is a valid configuration but there is no special handling. 'default' > is just treated as a name for the domain the same as 'abc' or any other > name. > > > > > > > "ldap_idmap_default_domain" > > > > - Is the entended use for this configuration directive? > > - If it is specified in one domain stanza in a multi-domain configuration > > will the configuration be honored across other configured domains? > > Each configured domain in sssd.conf like e.g [domain/abc] and > [domain/def] is independent of the other, so ldap_idmap_default_domain > is only for the individual section. > > The phrase 'default domain' in the man page entries refers to the > current configured domain in contrast to the discovered sub-domains. > > The 'ldap_idmap_default_domain' must only be set if the domain name you > choose in sssd.conf differs from the actual domain name. E.g. > > ... > [domain/home] > ... > ldap_idmap_default_domain = my.ad.domain > ... > > > HTH > > bye, > Sumit > > > > > > > Many thanks as always, > > > > > > -- lawrence > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: concerning "ldap_idmap_helper_table_size" directive inheritance
Thank you Sumit, that helps immensely. I think adding such a feature would be very useful, so I'll open a new ticket if you remind me where to enter one. I previously entered a ticket to have the PAM return codes used by the pam_sss module added to the man file for the module (as other modules do), but it has not appeared in any versions I've noticed yet. It would be most helpful for those of us that are incorporating MFA logic in our PAM stacks to explicitly know which return codes are implemented by the daemon. ... but, back to my original point, thank you :-) -- lawrence On Thu, Aug 30, 2018 at 6:26 AM Sumit Bose wrote: > On Thu, Aug 30, 2018 at 05:57:07AM -0400, Lawrence Kearney wrote: > > Hello again :-) > > > > After finding other directives that seemed to display the same behavior > in > > my environment I parsed the logs more closely and it appears to me that > the > > order of processing/logging directives is from the perspective of the > > joined domain first. In this case the child domain appears to take the > > configured directive and the parent is left at the default. Oddly, the > > parent domain is also referred to as a subdomain in the log. > > > > My setup again: > > > > parent domain: dvc.darkvixen.com (DC darkvixen161win.dvc.darkvixen.com) > > child domain: lab.dvc.darkvixen.com (DC > > darkvixen164win.lab.dvc.darkvixen.com) > > > > The relevant log entries: > > > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option > > ldap_idmap_range_min has value 20 > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option > > ldap_idmap_range_max has value 200020 > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option > > ldap_idmap_range_size has value 20 > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option > > ldap_idmap_helper_table_size has value 20 > > > > [sssd[be[lab.dvc.darkvixen.com]]] [ad_get_dc_servers_send] (0x0400): > > Looking up domain controllers in domain lab.dvc.darkvixen.com and site > > DarkVixenCorp > > [sssd[be[lab.dvc.darkvixen.com]]] [fo_add_server_to_list] (0x0400): > > Inserted primary server 'darkvixen164win.lab.dvc.darkvixen.com:389' to > > service 'AD' > > > > [sssd[be[lab.dvc.darkvixen.com]]] [new_subdomain] (0x0400): Creating [ > > dvc.darkvixen.com] as subdomain of [lab.dvc.darkvixen.com]! > > [sssd[be[lab.dvc.darkvixen.com]]] [sdap_domain_subdom_add] (0x0400): > > subdomain dvc.darkvixen.com is a new one, will create a new sdap domain > > object > > > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option > > ldap_idmap_range_min has value 20 > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option > > ldap_idmap_range_max has value 200020 > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option > > ldap_idmap_range_size has value 20 > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option > > ldap_idmap_helper_table_size has value 10 > > > > > > [sssd[be[lab.dvc.darkvixen.com]]] [ad_get_dc_servers_send] (0x0400): > > Looking up domain controllers in domain dvc.darkvixen.com and site > > DarkVixenCorp > > [sssd[be[lab.dvc.darkvixen.com]]] [fo_add_server_to_list] (0x0400): > > Inserted primary server 'darkvixen161win.dvc.darkvixen.com:389' to > service ' > > dvc.darkvixen.com' > > > > So, my questions now are: > > > > Do I understand this correctly? > > I think yes. For SSSD to domain you are joined to is the most important > one, all others are sub-domains. > > > Is the logging working as intended? > > yes, but I agree it is a bit irritating. Although the imap options for > sub-domains are shown only the one of the joined domain is of > importance. All domains use the same id-mapping setting, the ones from > the joined domain. Otherwise it would be hard to avoid id collisions. > > > Is there a way to expose the runtime configuration of the SSSD, including > > default configuration directive values (similar to /usr/sbin/sshd -T)? > > Currently not, there is 'sssctl config-check' but this does not display > values or defaults. There is https://pagure.io/SSSD/sssd/issue/3157 to > show values from the config file. You might want to add a comment about > showing the default values for all other options as well or open a new > ticket for this. > > bye, > Sumit > > > > > Many thanks, > > > > > > -- lawrence > > > > On Wed, Aug 29, 2018 at 7:50 AM Lawrence Kearney > > wrote: > > > > > > > > U
[SSSD-users] Re: concerning "ldap_idmap_helper_table_size" directive inheritance
Hello again :-) After finding other directives that seemed to display the same behavior in my environment I parsed the logs more closely and it appears to me that the order of processing/logging directives is from the perspective of the joined domain first. In this case the child domain appears to take the configured directive and the parent is left at the default. Oddly, the parent domain is also referred to as a subdomain in the log. My setup again: parent domain: dvc.darkvixen.com (DC darkvixen161win.dvc.darkvixen.com) child domain: lab.dvc.darkvixen.com (DC darkvixen164win.lab.dvc.darkvixen.com) The relevant log entries: [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option ldap_idmap_range_min has value 20 [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option ldap_idmap_range_max has value 200020 [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option ldap_idmap_range_size has value 20 [sssd[be[lab.dvc.darkvixen.com]]] [dp_get_options] (0x0400): Option ldap_idmap_helper_table_size has value 20 [sssd[be[lab.dvc.darkvixen.com]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain lab.dvc.darkvixen.com and site DarkVixenCorp [sssd[be[lab.dvc.darkvixen.com]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'darkvixen164win.lab.dvc.darkvixen.com:389' to service 'AD' [sssd[be[lab.dvc.darkvixen.com]]] [new_subdomain] (0x0400): Creating [ dvc.darkvixen.com] as subdomain of [lab.dvc.darkvixen.com]! [sssd[be[lab.dvc.darkvixen.com]]] [sdap_domain_subdom_add] (0x0400): subdomain dvc.darkvixen.com is a new one, will create a new sdap domain object [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option ldap_idmap_range_min has value 20 [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option ldap_idmap_range_max has value 200020 [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option ldap_idmap_range_size has value 20 [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option ldap_idmap_helper_table_size has value 10 [sssd[be[lab.dvc.darkvixen.com]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain dvc.darkvixen.com and site DarkVixenCorp [sssd[be[lab.dvc.darkvixen.com]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'darkvixen161win.dvc.darkvixen.com:389' to service ' dvc.darkvixen.com' So, my questions now are: Do I understand this correctly? Is the logging working as intended? Is there a way to expose the runtime configuration of the SSSD, including default configuration directive values (similar to /usr/sbin/sshd -T)? Many thanks, -- lawrence On Wed, Aug 29, 2018 at 7:50 AM Lawrence Kearney wrote: > > Using the SSSD (v1.13.4-34.7.1) joined to a child domain, the modified > "ldap_idmap_helper_table_size" directive value in the host sssd.conf is set > at the parent domain instead of the child domain, which remains at the > default of 10 (the child domain is a not a domain tree). > > Forest: dvc.darkvixen.com > Parent domain: dvc.darkvixen.com (parent non-decitated forest root domain) > Child domain: lab.dvc.darkvixen.com > > My understanding is that no "subdomain_provider" directive is needed for > this configuration, and the "subdomain_inherit" directive does not support > the inheritance of the "ldap_idmap_helper_table_size" directive. > > The sanitized sssd.conf: > > [sssd] > config_file_version = 2 > services = nss,pam,pac > domains = lab.dvc.darkvixen.com > > [nss] > filter_users = root > filter_groups = root > > [pam] > > [pac] > > [domain/lab.dvc.darkvixen.com] > id_provider = ad > access_provider = ad > > enumerate = false > cache_credentials = true > > ldap_idmap_helper_table_size = 20 > > ad_site = DarkVixenCorp > ad_hostname = darkvixen200.lab.dvc.darkvixen.com > > ad_access_filter = DOM:LAB.DVC.DARKVIXEN.COM: > (memberOf=CN=DARKVIXEN200_G,OU=LDAP,OU=SVS,DC=lab,DC=dvc,DC=darkvixen,DC=com) > > > From the domain log: > > [dp_get_options] (0x0400): Option ldap_idmap_helper_table_size has value 20 > [sssd[be[lab.dvc.darkvixen.com]]] [sdap_idmap_add_domain] (0x1000): > Adding domain [S-1-5-21-623326418-92578587-4020003380] as slice [8636] > [sssd[be[lab.dvc.darkvixen.com]]] [sysdb_idmap_store_mapping] (0x0100): > Adding new ID mapping [dvc.darkvixen.com > ][S-1-5-21-623326418-92578587-4020003380][8636] > > [sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option > ldap_idmap_helper_table_size has value 10 > [sssd[be[lab.dvc.darkvixen.com]]] [sdap_idmap_add_domain] (0x1000): > Adding domain [S-1-5-21-1157061662-2021606532-2751616909] as slice [4675] > [sysdb_idmap_store_mapping] (0x0100): Adding new ID mapping [ > lab.dvc.darkvixen.com][S-1-5-21-1157061662-202160653
[SSSD-users] concerning "ldap_idmap_helper_table_size" directive inheritance
Using the SSSD (v1.13.4-34.7.1) joined to a child domain, the modified
"ldap_idmap_helper_table_size" directive value in the host sssd.conf is set
at the parent domain instead of the child domain, which remains at the
default of 10 (the child domain is a not a domain tree).
Forest: dvc.darkvixen.com
Parent domain: dvc.darkvixen.com (parent non-decitated forest root domain)
Child domain: lab.dvc.darkvixen.com
My understanding is that no "subdomain_provider" directive is needed for
this configuration, and the "subdomain_inherit" directive does not support
the inheritance of the "ldap_idmap_helper_table_size" directive.
The sanitized sssd.conf:
[sssd]
config_file_version = 2
services = nss,pam,pac
domains = lab.dvc.darkvixen.com
[nss]
filter_users = root
filter_groups = root
[pam]
[pac]
[domain/lab.dvc.darkvixen.com]
id_provider = ad
access_provider = ad
enumerate = false
cache_credentials = true
ldap_idmap_helper_table_size = 20
ad_site = DarkVixenCorp
ad_hostname = darkvixen200.lab.dvc.darkvixen.com
ad_access_filter = DOM:LAB.DVC.DARKVIXEN.COM:
(memberOf=CN=DARKVIXEN200_G,OU=LDAP,OU=SVS,DC=lab,DC=dvc,DC=darkvixen,DC=com)
>From the domain log:
[dp_get_options] (0x0400): Option ldap_idmap_helper_table_size has value 20
[sssd[be[lab.dvc.darkvixen.com]]] [sdap_idmap_add_domain] (0x1000): Adding
domain [S-1-5-21-623326418-92578587-4020003380] as slice [8636]
[sssd[be[lab.dvc.darkvixen.com]]] [sysdb_idmap_store_mapping] (0x0100):
Adding new ID mapping [dvc.darkvixen.com
][S-1-5-21-623326418-92578587-4020003380][8636]
[sssd[be[lab.dvc.darkvixen.com]]] [dp_copy_options_ex] (0x0400): Option
ldap_idmap_helper_table_size has value 10
[sssd[be[lab.dvc.darkvixen.com]]] [sdap_idmap_add_domain] (0x1000): Adding
domain [S-1-5-21-1157061662-2021606532-2751616909] as slice [4675]
[sysdb_idmap_store_mapping] (0x0100): Adding new ID mapping [
lab.dvc.darkvixen.com][S-1-5-21-1157061662-2021606532-2751616909][4675]
>From the relevant DC:
~# Get-ADForest
ApplicationPartitions :
{DC=DomainDnsZones,DC=lab,DC=dvc,DC=darkvixen,DC=com,
DC=ForestDnsZones,DC=dvc,DC=darkvixen,DC=com,
DC=DomainDnsZones,DC=dvc,DC=darkvixen,DC=com}
CrossForestReferences : {}
DomainNamingMaster: DARKVIXEN161WIN.dvc.darkvixen.com
Domains : {dvc.darkvixen.com, lab.dvc.darkvixen.com}
ForestMode: Windows2012R2Forest
GlobalCatalogs: {DARKVIXEN161WIN.dvc.darkvixen.com,
DARKVIXEN164WIN.lab.dvc.darkvixen.com}
Name : dvc.darkvixen.com
PartitionsContainer :
CN=Partitions,CN=Configuration,DC=dvc,DC=darkvixen,DC=com
RootDomain: dvc.darkvixen.com
SchemaMaster : DARKVIXEN161WIN.dvc.darkvixen.com
Sites : {DarkVixenCorp}
SPNSuffixes : {}
UPNSuffixes : {}
Is this a bug fixed with later daemons or is there additional configuration
required ?
Many thanks,
-- lawrence
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] Re: concerning "ldap_idmap_range_size"
Sumit, Thank you that helps immensely. The goal of the referenced configuration is for new "direct integration" deployments in large AD environments for which we want to accommodate both growth and UID-GID alignment across systems that support the "ldap_idmap_helper_table_size" directive and those that don't. -- lawrence On Wed, Aug 29, 2018 at 5:01 AM Sumit Bose wrote: > On Tue, Aug 28, 2018 at 03:55:37PM -0400, Lawrence Kearney wrote: > > I have a question concerning values for the the "ldap_idmap_range_size" > > directive. I'm aware that v1.13.4 or better of the daemon supports > multiple > > slices for the same domain. My question goes to earlier versions of the > > daemon that do not, "and" the v1.13.4 or better versions of the daemon > > that do. > > > > In environments that have high RID values (>750,000), what disadvantages > > are there to setting the value of the "ldap_idmap_range_size" directive > to > > values above 1,000,000 to accommodate extraordinary large RID values. My > > common sense says the computational tax would be too high for a host to > be > > sustainable, but I wanted to ask. > > No it is ok to use larger value there is no additional tax. See the 'ID > MAPPING' section of the sssd-ad man page for details about how the > mapping is done. > > > > > So, in environments where I might want to have slice capacity > 200,000, > > what are the concerns, best practices, and briefly, why? > > You have to be aware that the UIDs and GIDs assigned to a user or a > group will change if you change ldap_idmap_range_size. If you already > used the default value for some time you have to migrate existing file > system permissions to the new values. Given that you should choose the > new value for ldap_idmap_range_size large enough so that chances are low > it has to be increased again. > > If you increase the size of a range the number of ranges will decrease. > Since ranges are selected for each domain with the help of a hashed > value the chance of a collision (a range assigned to two different > domains) will increase. But so far I'm not aware of a reported > collision so this is more a theoretical concern. > > HTH > > bye, > Sumit > > > > > > Many thanks > > > > > > -- Lawrence Kearney > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > -- Lawrence Kearney e: lawrence.kear...@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
[SSSD-users] concerning "ldap_idmap_range_size"
I have a question concerning values for the the "ldap_idmap_range_size" directive. I'm aware that v1.13.4 or better of the daemon supports multiple slices for the same domain. My question goes to earlier versions of the daemon that do not, "and" the v1.13.4 or better versions of the daemon that do. In environments that have high RID values (>750,000), what disadvantages are there to setting the value of the "ldap_idmap_range_size" directive to values above 1,000,000 to accommodate extraordinary large RID values. My common sense says the computational tax would be too high for a host to be sustainable, but I wanted to ask. So, in environments where I might want to have slice capacity > 200,000, what are the concerns, best practices, and briefly, why? Many thanks -- Lawrence Kearney ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
