View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005130SOGoWeb Generalpublic2020-08-21 16:002023-02-18 19:07
Reporterqseb Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformdebian buster 
Product Version5.0.0 
Summary0005130: linking CAS login with SMTP auth?
Description

My sogo installation is based on CAS authentication, and is workong fine for IMAP transactions.

Now I need to send mails with CAS ticket...

SOGoIMAPServer = "imaps://mail.mydomain.com:143/?tls=YES";
SOGoSMTPServer = "smtp://mail.mydomain:587/?tls=YES";
SOGoMailDomain = mydomain.com;
SOGoMailingMechanism = smtp;
SOGoSMTPAuthenticationType = PLAIN;

mail.mydomain.com is a postfix service doing sasl auth to a dovecot server. When SOGoSMTPAuthenticationType is set, I cannot send emails:

Aug 21 10:23:10 auth: Debug: client in: AUTH    1       PLAIN   service=imap    secured=tls     session=PVKrn2Ct4KCsEwAB        lip=172.19.0.12     rip=172.19.0.1  lport=143       rport=41184     local_name=mail.mydomain.com  ssl_cipher=TLS_AES_256_GCM_SHA384  ssl_cipher_bits=256      ssl_pfs=KxANY   ssl_protocol=TLSv1.3    resp=AGFkbWluLXNlYkBjZWxhcnNwb3J0cy5mcgBQVC1jMjM0ZGQ5ZTA2NmQ4NzEzYTQzNDFjNzRjYWFmNjg3YTk2OTM3Mjc3MDY4ZDA4MTA5YzUxMjYxMGUyNjJhM2Fm (previous base64 data may contain sensitive data)
Aug 21 10:23:10 auth: Debug: client passdb out: OK      1       user=user@mydomain.com
Aug 21 10:23:10 auth: Debug: master in: REQUEST 2355625985      185     1       f6370b42e6ab18811e8dd3959f5fd2ac        session_pid=186     request_auth_token
Aug 21 10:23:10 auth: Debug: master userdb out: USER    2355625985      user@mydomain.com        uid=102 gid=104 home=/var/mail/mydomain.com/user     auth_token=b2f224eb9c9e65d40397422727ed0baa56a451be
Aug 21 10:23:10 imap-login: Info: Login: user=<user@mydomain.com>, method=PLAIN, rip=172.19.0.1, lip=172.19.0.12, mpid=186, TLS, session=<PVKrn2Ct4KCsEwAB>
Aug 21 10:23:11 auth: Debug: auth client connected (pid=0)
Aug 21 10:23:11 auth: Debug: client in: AUTH    1       PLAIN   service=smtp    nologin lip=172.19.0.15 rip=172.19.0.1  secured
Aug 21 10:23:11 auth: Debug: client passdb out: CONT    1
Aug 21 10:23:11 auth: Debug: client in: CONT    1       YWRtaW4tc2ViQGNlbGFyc3BvcnRzLmZyAGFkbWluLXNlYkBjZWxhcnNwb3J0cy5mcgA1Ri01RjNGOUY4MC1GLTZDMkY5ODAw (previous base64 data may contain sensitive data)
AGFkbWluLXNlYkBjZWxhcnNwb3J0cy5mcgVGLTVGM0Y5RjgwLUYtNkMyRjk4MDA=
Aug 21 10:23:11 auth-worker(180): Debug: pam(user@mydomain.com,172.19.0.1): lookup service=dovecot
Aug 21 10:23:11 auth-worker(180): Debug: pam(user@mydomain.com,172.19.0.1): 0000001/1 style=1 msg=Password: 
Aug 21 10:23:11 auth-worker(180): Info: pam(user@mydomain.com,172.19.0.1): pam_authenticate() failed: Authentication failure (Password mismatch?) (given password: 5F-5F3F9F80-F-6C2F9800)
Aug 21 10:23:11 auth: Debug: ldap(user@mydomain.com,172.19.0.1): bind search: base=cn=accounts,dc=mydomain,dc=com filter=(&(mail=user@mydomain.com)(objectClass=inetorgperson))
Aug 21 10:23:11 auth: Debug: ldap(user@mydomain.com,172.19.0.1): result: mail=user@mydomain.com; mail unused
Aug 21 10:23:11 auth: Info: ldap(user@mydomain.com,172.19.0.1): Password mismatch (for LDAP bind) (given password: 5F-5F3F9F80-F-6C2F9800)
Aug 21 10:23:13 auth: Debug: client passdb out: FAIL    1       user=user@mydomain.com
Aug 21 10:23:13 imap(user@mydomain.com)<186><PVKrn2Ct4KCsEwAB>: Info: Logged out in=101 out=1092 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0

We can see first, an IMAP request, then 2 smtp auth request failing (pam_cas + ldap), because smtp password is wrong...

Note 1 : I manually succeed to authenticate on dovecot (via postfix) with cas ticket through pam:
Aug 21 10:22:24 auth: Debug: client in: AUTH    3       PLAIN   service=smtp    nologin lip=172.19.0.15 rip=172.19.0.1  secured resp=AGFkbWluLXNlYkBjZWxhcnNwb3J0cy5mcgBQVC1jMjM0ZGQ5ZTA2NmQ4NzEzYTQzNDFjNzRjYWFmNjg3YTk2OTM3Mjc3MDY4ZDA4MTA5YzUxMjYxMGUyNjJhM2Fm (previous base64 data may contain sensitive data)
Aug 21 10:22:24 auth-worker(180): Debug: pam(user@mydomain.com,172.19.0.1): lookup service=dovecot
Aug 21 10:22:24 auth-worker(180): Debug: pam(user@mydomain.com,172.19.0.1): 0000001/1 style=1 msg=Password: 
Aug 21 10:22:24 auth: Debug: client passdb out: OK      3       user=user@mydomain.com

Note 2 : I manually succeed too to authenticate on dovecot (via postfix) with LDAP cred:

Aug 21 10:17:34 auth: Debug: client in: AUTH    1       PLAIN   service=smtp    nologin lip=172.19.0.15 rip=172.19.0.1  secured resp=AGFkbWluLXNlYkBjZWxhcnNwb3J0cy5mcgBEa1dTYUhxV0dFRmhLeDVaRGFKYw== (previous base64 data may contain sensitive data)
Aug 21 10:17:34 auth: Debug: ldap(user@mydomain.com,172.19.0.1): bind search: base=cn=accounts,dc=mydomain,dc=com filter=(&(mail=user@mydomain.com)(objectClass=inetorgperson))
Aug 21 10:17:34 auth: Debug: ldap(user@mydomain.com,172.19.0.1): result: mail=user@mydomain.com; mail unused
Aug 21 10:17:34 auth: Debug: client passdb out: OK      1       user=user@mydomain.com

So I presume that SMTP auth sends the wrong password when SOGo login is based on a CAS ticket?

For the moment I have to disable PLAIN auth and let postfix to trust sogo... Did I miss something?

Tagsauthentication, PLAIN, SASL, SMTP

Activities

qseb

qseb

2020-08-23 16:08

reporter   ~0014715

As additional information, I disabled CAS login on sogo and enabled again smtp auth PLAIN. I log in sogo with my LDAP credentials.
Then sogo and postfix are transmitting to dovecot LDAP credentials, and SMTP PLAIN auth is successfull.
It confirms that CAS login is wrongly transmitted to sogo.
qseb

qseb

2020-08-23 16:09

reporter   ~0014716

typo:
It confirms that CAS login is wrongly transmitted to dovecot.
qseb

qseb

2020-08-26 21:17

reporter   ~0014730

Still investigating why wrong password (given password: 5F-5F3F9F80-F-6C2F9800) is sent to postfix when CAS authentication is enabled...
I played with memcache dumps and found intertesting records:

memccat --servers=localhost cas-id:5F-5F3F9F80-F-6C2F9800 =>
ST-de62fe9c14c97b7eb57aad1b5fc6a03d5c4e23c4c0ea29d2a29ea3af55ddf14a

memccat --servers=localhost cas-ticket:ST-de62fe9c14c97b7eb57aad1b5fc6a03d5c4e23c4c0ea29d2a29ea3af55ddf14a =>
{
"proxyTickets": {
"imaps://dovecot": "PT-243d95c8f625f0dcafcf16d6aafc3d23506b9e2b235c0bdd2431cc380cb37e01"
},
"identifier": "5F-5F3F9F80-F-6C2F9800",
"login": "user@mydomain.com",
"pgt": "PGT-1f2146590d9dc93f7739a9c95dd4728b0a21e30cda35cc97f300dcc9b20c8dac"
}

This last dump shows that "identifier" key is sent to postfix, instead of proxyTickets for "imaps:\/\/dovecot" service. Sogo should send "PT-243d95c8f625f0dcafcf16d6aafc3d23506b9e2b235c0bdd2431cc380cb37e01" as password!
The strange thing here, is that sogo can succeed to authenticate with a proxyticket on dovecot, but do not use it to authenticate on postfix...
qseb

qseb

2020-08-28 13:04

reporter   ~0014732

Last edited: 2020-09-08 15:34

I patched SoObjects/SOGo/SOGoMailer.m with some hardcoded lines, since I'm not a developer :(

on top of file, add:

#import "SOGoCASSession.h"

I replaced line 225:

NSString *currentTo, *login, *password;

with:

NSString *currentTo, *login, *password, *service, *scheme, *serverhost;

and appended:

SOGoCASSession *session;

Now the code after:

password = [authenticator passwordInContext: woContext];

At this step password is an identifier (ie: 68577-5F48FC00-1-1FBC5B60)
We can call cassession functions to pass this identifier and retrieve proxyticket as password:

          session = [SOGoCASSession CASSessionWithIdentifier: password
                                               fromProxy: NO];
          //hardcoded sheme:
          scheme = @"imaps";
          //hardcoded serverhost:
          serverhost = @"dovecot";
          service = [NSString stringWithFormat: @"%@://%@", scheme, serverhost"];
          [session invalidateTicketForService: service];
          password = [session ticketForService: service];

I can now login with CAS on sogo and postfix!!!

Other routing case should be added to detect if auth should be CAS/SAML/whatever...
qseb

qseb

2021-03-31 17:14

reporter   ~0015174

any news for developing this feature?
qseb

qseb

2023-02-18 19:07

reporter   ~0016662

small bump 2 years later...

Issue History

Date Modified Username Field Change
2020-08-21 16:00 qseb New Issue
2020-08-23 14:43 qseb Tag Attached: SASL
2020-08-23 14:43 qseb Tag Attached: authentication
2020-08-23 14:43 qseb Tag Attached: SMTP
2020-08-23 14:43 qseb Tag Attached: PLAIN
2020-08-23 16:08 qseb Note Added: 0014715
2020-08-23 16:09 qseb Note Added: 0014716
2020-08-26 21:17 qseb Note Added: 0014730
2020-08-28 13:04 qseb Note Added: 0014732
2020-09-08 15:34 francis Note Edited: 0014732
2021-03-31 17:14 qseb Note Added: 0015174
2022-01-12 19:37 francis Description Updated
2023-02-18 19:07 qseb Note Added: 0016662