Bug 1722159 - ntlm plugin: ntlm_v2 option is not read from the configuration file by client
Summary: ntlm plugin: ntlm_v2 option is not read from the configuration file by client
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cyrus-sasl
Version: 7.10
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Simo Sorce
QA Contact: BaseOS QE Security Team
URL: https://github.com/cyrusimap/cyrus-sa...
Whiteboard:
: 1757983 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-19 14:42 UTC by Jaroslav Škarvada
Modified: 2019-10-03 19:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-19 17:34:47 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4253821 Troubleshoot None ntlm_v2 option of cyrus-sasl-ntlm doesn't work with postfix 2019-06-28 12:00:08 UTC

Description Jaroslav Škarvada 2019-06-19 14:42:42 UTC
Description of problem:
It seems the ntlm_v2 option is not read from the config file for the SASL client.

Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.26-23.el7.x86_64
cyrus-sasl-ntlm-2.1.26-23.el7.x86_64

How reproducible:
Always

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

Actual results:
Postfix calls 'sasl_client_init' with service name set to 'smtp', but file /etc/sasl2/smtp.conf is not read and ntlm_v2 is still set to '(null)'.

Expected results:
/etc/sasl2/smtp.conf read and ntlm_v2 initialized to 'yes', so the NTLM plugin will use the ntlm_v2.

Additional info:

Comment 2 Jaroslav Škarvada 2019-06-19 14:43:49 UTC
Steps to Reproduce:
1. Setup postfix to use NTLM SASL auth
2. echo "ntlm_v2: yes" > /etc/sasl2/smtp.conf
3.

Comment 3 Simo Sorce 2019-06-19 14:50:15 UTC
Can you double check the name of the file?
The default name for postifx should be smtpd.conf and not smtp.conf

Comment 4 Simo Sorce 2019-06-19 14:51:30 UTC
please provide postifx version used and config file if in doubt, as the sasl service name can be set there

Comment 5 Simo Sorce 2019-06-19 14:53:45 UTC
I just noticed you mention both postfix and sendmail ... I guess I am confused now.

Comment 6 Jaroslav Škarvada 2019-06-19 14:58:03 UTC
(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).

Comment 7 Jaroslav Škarvada 2019-06-19 14:58:42 UTC
(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.

Comment 8 Jaroslav Škarvada 2019-06-19 14:59:40 UTC
(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.

Comment 9 Simo Sorce 2019-06-19 15:04:05 UTC
Uhmm you seem to be using a : in the test, but afaik the option should be:
ntlm_v2 yes
can you try with that ?

Comment 10 Jaroslav Škarvada 2019-06-19 15:07:11 UTC
(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.

Comment 11 Simo Sorce 2019-06-19 15:14:08 UTC
can you provide the postfix configuration?
Also nevermind the ':', I misread a doc.

Comment 12 Juan Manuel Santos 2019-06-19 15:15:40 UTC
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@example.com

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@example.com: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.

Comment 13 Simo Sorce 2019-06-19 15:49:31 UTC
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 ?

Comment 14 Jaroslav Škarvada 2019-06-19 16:04:45 UTC
(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.

Comment 15 Simo Sorce 2019-06-19 16:31:19 UTC
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.

Comment 16 Jaroslav Škarvada 2019-06-19 16:55:09 UTC
(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?

Comment 17 Simo Sorce 2019-06-19 17:34:47 UTC
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.

Comment 18 Jaroslav Škarvada 2019-06-20 08:02:50 UTC
Upstream report:
https://github.com/cyrusimap/cyrus-sasl/issues/574

Comment 19 Simo Sorce 2019-10-02 21:31:07 UTC
*** Bug 1757983 has been marked as a duplicate of this bug. ***

Comment 20 Simo Sorce 2019-10-03 19:14:34 UTC
*** Bug 1757983 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.