Bug 1722159

Steps to Reproduce:
1. Setup postfix to use NTLM SASL auth
2. echo "ntlm_v2: yes" > /etc/sasl2/smtp.conf
3.

Can you double check the name of the file?
The default name for postifx should be smtpd.conf and not smtp.conf

please provide postifx version used and config file if in doubt, as the sasl service name can be set there

I just noticed you mention both postfix and sendmail ... I guess I am confused now.

(In reply to Simo Sorce from comment #3)
> Can you double check the name of the file?
> The default name for postifx should be smtpd.conf and not smtp.conf

I tried both just to be sure, but for the client it calls smtp.conf (I checked by debugging).

(In reply to Simo Sorce from comment #5)
> I just noticed you mention both postfix and sendmail ... I guess I am
> confused now.

Sorry typo, I meant postfix.

(In reply to Jaroslav Škarvada from comment #6)
> (In reply to Simo Sorce from comment #3)
> > Can you double check the name of the file?
> > The default name for postifx should be smtpd.conf and not smtp.conf
> 
> I tried both just to be sure, but for the client it calls smtp.conf (I
> checked by debugging).

Well not smtp.conf, but it sets service name to 'smtp' which should result in smtp.conf.

Uhmm you seem to be using a : in the test, but afaik the option should be:
ntlm_v2 yes
can you try with that ?

(In reply to Simo Sorce from comment #9)
> Uhmm you seem to be using a : in the test, but afaik the option should be:
> ntlm_v2 yes
> can you try with that ?

No, it seems it doesn't help. Also it seems the file is not accessed by the OS.

can you provide the postfix configuration?
Also nevermind the ':', I misread a doc.

Hello Simo,

I'm a contributor in case # 02398867, Jaroslav has been helping me troubleshoot this. Customer recompiled Cyrus-SASL in order to have the v2 option hardcoded to yes (needed due to security policies on his Office 365 instance).

So, while I don't have an Office 365 instance to test this, I did build a couple of Postfix servers, one to act as a client authenticating against the other, acting as a server.

=================================================================

On the Postfix server I installed:

cyrus-sasl-lib-2.1.26-23.el7.x86_64
cyrus-sasl-ntlm-2.1.26-23.el7.x86_64
cyrus-sasl-2.1.26-23.el7.x86_64
cyrus-sasl-plain-2.1.26-23.el7.x86_64

Postfix configuration (only relevant lines shown):

smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = smtpd

SASL configuration:

[root@r76-rs-server ~]# cat /etc/sasl2/smtpd.conf 
pwcheck_method: auxprop
mech_list: ntlm
ntlm_v2: yes

I manually created a SASL DB to test for this:

# saslpasswd2 -c john

saslauthd is enabled and running:

[root@r76-rs-server ~]# systemctl status saslauthd
● saslauthd.service - SASL authentication daemon.
   Loaded: loaded (/usr/lib/systemd/system/saslauthd.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2019-06-19 04:36:02 EDT; 6h ago
  Process: 4302 ExecStart=/usr/sbin/saslauthd -m $SOCKETDIR -a $MECH $FLAGS (code=exited, status=0/SUCCESS)
 Main PID: 4303 (saslauthd)
   CGroup: /system.slice/saslauthd.service
           ├─4303 /usr/sbin/saslauthd -m /run/saslauthd -a pam
           ├─4304 /usr/sbin/saslauthd -m /run/saslauthd -a pam
           ├─4305 /usr/sbin/saslauthd -m /run/saslauthd -a pam
           ├─4306 /usr/sbin/saslauthd -m /run/saslauthd -a pam
           └─4307 /usr/sbin/saslauthd -m /run/saslauthd -a pam

Jun 19 04:36:02 r76-rs-server.example.com systemd[1]: Starting SASL authentication daemon....
Jun 19 04:36:02 r76-rs-server.example.com saslauthd[4303]: detach_tty      : master pid is: 4303
Jun 19 04:36:02 r76-rs-server.example.com saslauthd[4303]: ipc_init        : listening on socket: /run/saslauthd/mux
Jun 19 04:36:02 r76-rs-server.example.com systemd[1]: Started SASL authentication daemon..
Hint: Some lines were ellipsized, use -l to show in full.


=================================================================

On the Postfix client:

[root@r76-rs-client ~]# rpm -qa|grep cyrus
cyrus-sasl-lib-2.1.26-23.el7.x86_64
cyrus-sasl-plain-2.1.26-23.el7.x86_64
cyrus-sasl-ntlm-2.1.26-23.el7.x86_64


Postfix configuration (only relevant lines shown):

relayhost = r76-rs-server
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_path = smtp

[root@r76-rs-client ~]# cat /etc/postfix/sasl_passwd
r76-rs-server	john:john


My understanding from looking at upstream documentation on Postfix site, is that smtp_sasl_path (empty by default) gives the filename that the SASL plugin should load. In this case, the filename should be (full path and suffix added):

/etc/sasl2/smtp.conf

Its contents:

[root@r76-rs-client ~]# cat /etc/sasl2/smtp.conf 
ntlm_v2: yes

=================================================================

Bear in mind that I cannot actually force only v2 authentication on the Postfix server (or at least I don't know how to do), so at this point I would be just happy with knowing that the configuration file was loaded. The authentication part is working fine, NTLM is used and the client is able to authenticate and send email without issues. In fact I can change the password to an invalid one and the message gets rejected due to failed authentication.

Now, since I cannot force v2 on Postfix server, I am only interested in getting the config file to load. To this end I tried two approaches:

- stracing the Postfix master process on the Postfix client, sending an email, and analyzing the strace output. There never is an open() call for /etc/sasl2/smtp.conf.
- Since it was possible (I am not familiar with Postfix's codebase) that the file was opened early on, and I didn't want to strace the master process manually (outside of running it via systemd), I then configured the following audit rules:

[root@r76-rs-client ~]# auditctl -l
-w /etc/sasl2/smtp.conf -p rwxa -k sasl-file
-w /usr/lib/sasl2/smtp.conf -p rwxa -k sasl-file-lib
-w /usr/lib64/sasl2/smtp.conf -p rwxa -k sasl-file-lib64

Note that, because the documentation is a little hazy on the paths where the config file was located, I put in all three, and made sure to copy the smtp.conf file to each path.

With this in place, I restarted Postfix and sent an email again. None of these audit rules were triggered, so the file was never loaded.

I can make available any debug log files/strace/whatever might be needed. I could even give you access to these VMs should you need it.

Are you doing the strace/auditing on the client or on the server ?
What version of postfix ?
Does the auditing show access to the file on the other server ?

The defaults for syrus-sasl on RHL7.6 are to look into /usr/lib64/sasl2/ and /etc/sasl2/

Can you add smtp_sasl_mechanism_filter = ntlm to the client to make sure it is forcing the use of ntlm ?

(In reply to Simo Sorce from comment #13)
> Are you doing the strace/auditing on the client or on the server ?
Client

> What version of postfix ?
postfix-2.10.1-7.el7.x86_64

> Does the auditing show access to the file on the other server ?
>
Server worked for me, client didn't.
 
> The defaults for syrus-sasl on RHL7.6 are to look into /usr/lib64/sasl2/ and
> /etc/sasl2/
>
I have tried just /etc/sasl2
 
> Can you add smtp_sasl_mechanism_filter = ntlm to the client to make sure it
> is forcing the use of ntlm ?

It uses the NTLM, because I was able to add breakpoint to the line 2025 of the /cyrus-sasl/rhel-7.6/cyrus-sasl-2.1.26-dev/plugins/ntlm.c and it clearly showed that during the NTLM auth the control flow reached the line 2025, but the 'sendv2' string was uninitialized there (or more precisely initialized to the string '(null)' and not to 'yes')

I also quickly checked the 'sasl_client_init' code in the cyrus-sasl and when compared with the 'sasl_server_init' it seems it's missing the configuration file loader.

Maybe Juan Manuel Santos could later provide more information because he did independent debugging of this problem.

You are correct, configuration fiels are loaded only for server applications apparently.
There is no code in sasl to load a configuration for client applications, I assume thos eneed to pass options via SASL_CB_GETOPT callbacks.

That's how cyrus-sasl is architected apparently.
So I do not think we can "fix" this issue.

(In reply to Simo Sorce from comment #15)
> You are correct, configuration fiels are loaded only for server applications
> apparently.
> There is no code in sasl to load a configuration for client applications, I
> assume thos eneed to pass options via SASL_CB_GETOPT callbacks.
> 
> That's how cyrus-sasl is architected apparently.
> So I do not think we can "fix" this issue.

Well, this is bad, because there is currently no way in postfix how to set this option, so the NTLMv2 on client is unusable now with it. Postfix relies on the auth layer - the cyrus-sasl regarding the auth details to be abstracted from the details.

Logically if there is config file for server, I think there should be one for the client. Maybe upstream RFE?

You can try to file an RFE, unfortunately cyrus-sasl upstream is not very responsive lately.

I have to close this bug as CANTFIX for now.

Upstream report:
https://github.com/cyrusimap/cyrus-sasl/issues/574

*** Bug 1757983 has been marked as a duplicate of this bug. ***

*** Bug 1757983 has been marked as a duplicate of this bug. ***