Adding a bunch of ldap and krb5 settings to domain.conf

[pedmon]

This is adding a bunch of additional ldap and krb5 settings to domain.conf that we need for our set up.

[michael-riddle]

The following parameters are nowhere to be found in the man page for sssd.conf version 2.9.5 (which is the version that ships with rhel9 by default):

• ldap_referrals
• ldap_page_size
• ldap_id_use_start_tls
• ldap_default_bind_dn
• ldap_default_authtok_type
• ldap_default_authtok
• ldap_tls_reqcert
• ldap_schema
• ldap_user_object_class
• ldap_user_home_directory
• ldap_group_object_class
• ldap_access_order
• ldap_account_expire_policy
• ldap_force_upper_case_realm
• krb5_canonicalize

Could you explain where these extra parameters are coming from?

[michael-riddle]

As I was looking through the module I noticed the "custom_config" option. Have you all tried to use this parameter to achieve what you're trying to achieve with this PR? It allows you to create a managed drop-in file under /etc/sssd/conf.d with any custom content you want/need.

[pedmon]

These are definitely valid option as I have a RHEL 9 server using them. Looks like they are doced here: https://linux.die.net/man/5/sssd-ldap and here: https://linux.die.net/man/5/sssd-krb5 We definitely need them for our domain config but I don't see a custom_config option for domain. I do see it for service but not for specific domain. I also see config::entry which looks to be for arbitrary drop-in. Since this is a domain config I would prefer to not create another dropin but use the domain config space. That said a better option may be to add a custom_config section to the domain section as sssd has 30 billion options and keeping all of them hardcoded is probably not the best strategy. If you like I can refactor this to copy the logic for custom_config found in the services section so that way domains can also have custom config. Let me know if you want me to do this.

[silug]

That said a better option may be to add a custom_config section to the domain section as sssd has 30 billion options and keeping all of them hardcoded is probably not the best strategy. If you like I can refactor this to copy the logic for custom_config found in the services section so that way domains can also have custom config. Let me know if you want me to do this.

That seems like a good plan to me. 👍

[pedmon]

Okay, I've fixed it so that there is now a custom_options hash that can be passed in. Let me know if you need any other changes.