Why would it be more complex to define in you application LDAP settings that have already been defined, BTW, in SSSD (or directly in NSS if not Redhat/CentOS).
LDAP configuration doesn't change that much and SSSD provides, to me, only the redirection (plus some caching etc... but this it out of scope in this debate)
Furthermore, there is something one needs to take in account:
- PAM deals with authentication only, and when authentication directly done through PAM, it assumes RFC2307 (bis if any) has been deployed and configured in LDAP. (RFC2307 is NIS like implementation in LDAP)
- Then profiling is based, at best, still when using SSSD, on RFC2307 attributes or group membership, meaning you don't access LDAP directly here but through abstraction layer assuming that you look for POSIX account which may be stored either in LDAP or in local file or elsewhere, it doesn't matter and that's really where this approach does help and shine.
On the other hand, if your application needs to rely on different attributes (well, say mailaddress ), PAM doesn't help because PAM = authentication, and SSSD doesn't neither. Your mail server will have to access LDAP server directly.
Sure you may have specific SSSD implementation but principle remains the same.
To make it short, in closed "Redhat/FreIPA" local implementation, everything looks like to work through SSSD but as soon as you need to do something really relying on LDAP as directory provider (I mean aside authentication and basic group membership), I don't understand how it could work without telling your application where LDAP server is, where to look at and which attributes to use. Did I say this is complex? no, to me it's not even if it requires some basic (very basic) training