pam authentication

markVnl

Discovering all the possible configurations, pam authentication would suite me best;
This despite it seems to be a legacy option rather than a full supported function

And it works like a charm!

…however…

Running Kopano as an system user with UID < 1000 floods the system journal on every mouse click in the Kopano-webapp:

.. kopano-server[25644]: pam_sss(password-auth:auth): authentication success; logname= uid=995 euid=995 tty= ruser= rhost= user=mark
.. kopano-server[25644]: pam_sss(password-auth:auth): authentication success; logname= uid=995 euid=995 tty= ruser= rhost= user=mark
.. kopano-server[25644]: pam_sss(password-auth:auth): authentication success; logname= uid=995 euid=995 tty= ruser= rhost= user=mark
.. kopano-server[25644]: pam_sss(password-auth:auth): authentication success; logname= uid=995 euid=995 tty= ruser= rhost= user=mark
.. kopano-server[25644]: pam_sss(password-auth:auth): authentication success; logname= uid=995 euid=995 tty= ruser= rhost= user=mark

With some tinkering in the pam.d units this can be silenced; but would like to persuade Kopano to open a (user)session.
Is there an option/way to open a pam-session?

Some Background:
I’m squeezing Kopano in to a centos based distro Nethserver which uses its local Ldap/Samba-AD merely as an authentication source exposing it to applications though sssd (-pam). This has the benefit it also fits into many environments with external account-providers whether this is MS-AD, openLdap, 389 Directory Server …
Downside is if a local account provider is used, just a minimal amount of user data is stored in the ldap. And Kopano does not have much to play with…

fbartels

@markvnl said in pam authentication:

Downside is if a local account provider is used, just a minimal amount of user data is stored in the ldap. And Kopano does not have much to play with…

Since I am really not a fan of the Unix backend: even if there is not much data in the local LDAP, it’s probably not less than what the Unix backend can provide (at best it is equal).

It sounds a bit like Nethserver offers a similar mode of operation that Univention is offering (I think called member mode there). Join into an ad and replicate user data locally (while verifying user passwords via Kerberos).

Does that sound about right?

markVnl

@fbartels said in pam authentication:

Since I am really not a fan of the Unix backend: even if there is not much data in the local LDAP, it’s probably not less than what the Unix backend can provide (at best it is equal).

Don’t get me wrong i see the potential running Kopano with a “slapped” kapano.schema.! Did this on the samba AD…/there is no way back/… I’m searching for a nice entry level., and pam is nice and clean.

@fbartels said in pam authentication:

It sounds a bit like Nethserver offers a similar mode of operation that Univention is offering (I think called member mode there). Join into an ad and replicate user data locally (while verifying user passwords via Kerberos).

sssd is quite a nice service, it does cache user-credentials to beable to logon if the account provider is unreachable, but is not you can’t call it replication.
BTW it is no problem to bind to to local account-provider whetter it is AD or openLdap. just trying to get the most out of Kopano without depending too much on the ldap comment that implies filling the database “manually”

The rough setup of both (pam/ad-ldap) configurations-modules work, have to decide which one i going to pursuit…
(for my personal use i going all in and update the schema!)