From michal.bruncko at zssos.sk Fri Apr 10 18:53:24 2020 From: michal.bruncko at zssos.sk (Michal Bruncko) Date: Sat, 11 Apr 2020 00:53:24 +0200 Subject: NTLM authentication not working Message-ID: Hello I am trying to use NTLM autentication (using cyrus-sasl-ntlm) for cyrus-imapd server for user authentication. in imapd.conf: sasl_ntlm_server:?????? dc1.example.com sasl_ntlm_v2:?????????? yes sasl_mech_list:???????? PLAIN NTLM LOGIN dc1.example.com is samba 4 AD DC, I have tried also samba 4.2 in NT4 PDC mode, but with same results. on both samba servers the "server signing" global parameter set to "auto" (i.e. accepting non-signed connections is allowed - mandatory for this NTLM SASL plugin as what I read), but I cannot get authentication working. in maillog: Apr 10 23:32:30 mail cyrus/imaps[10078]: NTLM server step 1 Apr 10 23:32:30 mail cyrus/imaps[10078]: client flags: ffff8207 Apr 10 23:32:33 mail cyrus/imaps[10078]: badlogin: client.example.local [172.17.0.13] NTLM [SASL(0): successful result: ] NTLM plugin on mailserver is communicating with samba server(s) over port 139. mailserver always exchanges with sambaserver four NBT packets, here is full stream: 23:47:14.971695 IP 192.168.0.31.139 > 192.168.0.51.36196: Flags [S.], seq 2264619136, ack 3113401271, win 14280, options [mss 1440,sackOK,TS val 3147289764 ecr 1769474260,nop,wscale 5], length 0 23:47:14.972300 IP 192.168.0.51.36196 > 192.168.0.31.139: Flags [.], ack 1, win 113, options [nop,nop,TS val 1769474263 ecr 3147289764], length 0 23:47:14.972364 IP 192.168.0.51.36196 > 192.168.0.31.139: Flags [P.], seq 1:73, ack 1, win 113, options [nop,nop,TS val 1769474263 ecr 3147289764], length 72 NBT Session Packet: Session Request 23:47:14.972386 IP 192.168.0.31.139 > 192.168.0.51.36196: Flags [.], ack 73, win 447, options [nop,nop,TS val 3147289765 ecr 1769474263], length 0 23:47:14.979752 IP 192.168.0.31.139 > 192.168.0.51.36196: Flags [P.], seq 1:5, ack 73, win 447, options [nop,nop,TS val 3147289772 ecr 1769474263], length 4 NBT Session Packet: Session Granted 23:47:14.980199 IP 192.168.0.51.36196 > 192.168.0.31.139: Flags [.], ack 5, win 113, options [nop,nop,TS val 1769474271 ecr 3147289772], length 0 23:47:14.982440 IP 192.168.0.51.36196 > 192.168.0.31.139: Flags [P.], seq 73:124, ack 5, win 113, options [nop,nop,TS val 1769474273 ecr 3147289772], length 51 NBT Session Packet: Session Message 23:47:14.985406 IP 192.168.0.31.139 > 192.168.0.51.36196: Flags [P.], seq 5:112, ack 124, win 447, options [nop,nop,TS val 3147289778 ecr 1769474273], length 107 NBT Session Packet: Session Message 23:47:15.025563 IP 192.168.0.51.36196 > 192.168.0.31.139: Flags [.], ack 112, win 113, options [nop,nop,TS val 1769474317 ecr 3147289778], length 0 i.e.: 1. from mailserver: NBT Session Packet: Session Request 2. from sambaserver: NBT Session Packet: Session Granted 3. from mailserver: NBT Session Packet: Session Message 4. from sambaserver: NBT Session Packet: Session Message which corresponds to following samba log messages: [2020/04/10 23:52:00.583266,? 3] ../source3/smbd/process.c:1880(process_smb) ? Transaction 0 of length 51 (0 toread) [2020/04/10 23:52:00.583359,? 3] ../source3/smbd/process.c:1489(switch_message) ? switch message SMBnegprot (pid 28556) conn 0x0 [2020/04/10 23:52:00.586326,? 3] ../source3/smbd/negprot.c:576(reply_negprot) ? Requested protocol [NT LM 0.12] [2020/04/10 23:52:00.586887,? 3] ../source3/smbd/negprot.c:377(reply_nt1) ? not using SPNEGO [2020/04/10 23:52:00.586969,? 3] ../source3/smbd/negprot.c:684(reply_negprot) ? Selected protocol NT LM 0.12 [2020/04/10 23:52:00.591116,? 3] ../source3/smbd/server_exit.c:249(exit_server_common) ? Server exit (failed to receive smb request) basically sambaserver accepted session request, accepted protocol type (NT LM 0.12) request from mailserver (returning STATUS_SUCCESS to mailclient), but mailserver is not responding at all and gracefully closes connection.? there is nothing else exchanged. basically NTLM client creates NBT session and proposes protocol which samba accepted, but then it ends. question is what I am doing wrong? did I miss something? I know that based from existing open issues the "sasl_ntlm_v2" parameter is ignored, but I have tried to to hardcode it, but it ends with same results - there is no difference. mailserver is centos 7 system with following packages: cyrus-sasl-ntlm-2.1.26-23.el7.x86_64 cyrus-imapd-2.4.17-15.el7.x86_64 but I have tried to test this NTLM plugin also on older centos 6 system as mailserver (also with cyrus-imapd server) and the behaviour is completely same (error message in maillog, packets exchanged): cyrus-sasl-ntlm-2.1.23-15.el6_6.2.x86_64 cyrus-imapd-2.3.16-15.el6.x86_64 thanks for any help on this michal From d.faller at live.de Sun Apr 12 07:29:01 2020 From: d.faller at live.de (David Faller) Date: Sun, 12 Apr 2020 11:29:01 +0000 Subject: Cyradm saslauthd issue Message-ID: Dear all, I have a question of my configuration, we?re using multiple domains and the users are stored on our samba ad dc server. In past I wanted to prevent the issue, that user can login with their username and not with a fqdn mail address. I had solved this issue by editing the /etc/default/saslauthd service file and added ?-r? at options in the end: # # Settings for saslauthd daemon # Please read /usr/share/doc/sasl2-bin/README.Debian for details. # # Should saslauthd run automatically on startup? (default: no) START=yes # Description of this saslauthd instance. Recommended. # (suggestion: SASL Authentication Daemon) DESC="SASL Authentication Daemon" # Short name of this saslauthd instance. Strongly recommended. # (suggestion: saslauthd) NAME="saslauthd" # Which authentication mechanisms should saslauthd use? (default: pam) # # Available options in this Debian package: # getpwent -- use the getpwent() library function # kerberos5 -- use Kerberos 5 # pam -- use PAM # rimap -- use a remote IMAP server # shadow -- use the local shadow password file # sasldb -- use the local sasldb database file # ldap -- use LDAP (configuration is in /etc/saslauthd.conf) # # Only one option may be used at a time. See the saslauthd man page # for more information. # # Example: MECHANISMS="pam" MECHANISMS="ldap" # Additional options for this mechanism. (default: none) # See the saslauthd man page for information about mech-specific options. MECH_OPTIONS="" # How many saslauthd processes should we run? (default: 5) # A value of 0 will fork a new process for each connection. THREADS=5 # Other options (default: -c -m /var/run/saslauthd) # Note: You MUST specify the -m option or saslauthd won't run! # # WARNING: DO NOT SPECIFY THE -d OPTION. # The -d option will cause saslauthd to run in the foreground instead of as # a daemon. This will PREVENT YOUR SYSTEM FROM BOOTING PROPERLY. If you wish # to run saslauthd in debug mode, please run it by hand to be safe. # # See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information. # See the saslauthd man page and the output of 'saslauthd -h' for general # information about these options. # # Example for chroot Postfix users: "-c -m /var/spool/postfix/var/run/saslauthd" # Example for non-chroot Postfix users: "-c -m /var/run/saslauthd" # # To know if your Postfix is running chroot, check /etc/postfix/master.cf. # If it has the line "smtp inet n - y - - smtpd" or "smtp inet n - - - - smtpd" # then your Postfix is running in a chroot. # If it has the line "smtp inet n - n - - smtpd" then your Postfix is NOT # running in a chroot. OPTIONS="-r -c -m /var/run/saslauthd" My saslauthd.config file here use an other filter than default one: ldap_servers: ldap://XXXXX ldap_search_base: dc= XXX,dc=dir #ldap_filter: sAMAccountName=%U ldap_filter: userPrincipalName=%u #ldap_version: 3 ldap_auth_method: bind ldap_bind_dn: cn=Administrator,cn=Users,dc=XXX,dc=dir ldap_bind_pw: XXX #ldap_scope: sub ldap_debug: -1 Here I have problem this config works fine all users can only sign in with their full e-mail address So max.murry at web.de can login AND Max.murry can?t login. This is working fine, but when I want to use cyradm I need to switch the filter on /etc/saslauthd.conf to sAMAccountName=%U If I don?t do this I can?t access the cyradm tool, perhaps someone could help here? I think the problem is here the same, authentication are only allowed with a fqdn but the linux user cyrus has no domain ending. Best Regards, David Faller -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwhite at olp.net Mon Apr 13 09:38:07 2020 From: dwhite at olp.net (Dan White) Date: Mon, 13 Apr 2020 08:38:07 -0500 Subject: Cyradm saslauthd issue In-Reply-To: References: Message-ID: <20200413133807.GA983317@olp.net> On 04/12/20?11:29?+0000, David Faller wrote: >I have a question of my configuration, >we?re using multiple domains and the users are stored on our samba ad dc server. > >In past I wanted to prevent the issue, that user can login with their username and not with a fqdn mail address. > >I had solved this issue by editing the /etc/default/saslauthd service file and added ?-r? at options in the end: > ># Settings for saslauthd daemon >START=yes >DESC="SASL Authentication Daemon" >NAME="saslauthd" >MECHANISMS="ldap" >MECH_OPTIONS="" >THREADS=5 >OPTIONS="-r -c -m /var/run/saslauthd" > >My saslauthd.config file here use an other filter than default one: > >ldap_servers: ldap://XXXXX >ldap_search_base: dc= XXX,dc=dir >#ldap_filter: sAMAccountName=%U >ldap_filter: userPrincipalName=%u > >#ldap_version: 3 >ldap_auth_method: bind >ldap_bind_dn: cn=Administrator,cn=Users,dc=XXX,dc=dir >ldap_bind_pw: XXX >#ldap_scope: sub >ldap_debug: -1 > >Here I have problem this config works fine all users can only sign in with their full e-mail address > >So max.murry at web.de can login AND Max.murry can?t login. > >This is working fine, > >but when I want to use cyradm I need to switch the filter on /etc/saslauthd.conf to sAMAccountName=%U >If I don?t do this I can?t access the cyradm tool, perhaps someone could help here? >I think the problem is here the same, authentication are only allowed with a fqdn but the linux user cyrus has no domain ending. Hi David, What error do you get when you attempt to login as the cyrus user? Try adding 'cyrus@' to your admins entry in impad.conf. Depending on your deployment, that may not be sufficient for administering all of your domains. You may need a unique cyrus@ account for each domain, with each entry listed within an admins config line. Since your problem is only with cyradm, consider running a second imapd instance, using local sasldb authentication to, support cyradm, i.e.: Within /etc/cyrus.conf: imap cmd="imapd" listen="192.168.0.1:imap" prefork=0 imaplocal cmd="imapd" listen="127.0.0.1:imap" prefork=0 Then within /etc/imapd.conf, carve out a unique sasl pwcheck method for imaplocal: imaplocal_sasl_pwcheck_method: auxprop imaplocal_sasl_auxprop_plugin: sasldb #imaplocal_sasl_mech_list: PLAIN Then you would maintain the cyrus user's password with saslpasswd2. -- Dan White Network Admin Lead From simo at redhat.com Mon Apr 13 10:18:02 2020 From: simo at redhat.com (Simo Sorce) Date: Mon, 13 Apr 2020 10:18:02 -0400 Subject: License in new files Message-ID: Hello, In https://github.com/cyrusimap/cyrus-sasl/pull/598 I asked a question given I forgot to fix (C) in files we recently merged. The question is simply: what license needs to be set on files? I personally prefer to give a very liberal license like 2 clause BSD, when a non-copyleft work is involved. Generally that license is compatible with anything else already on the work and won't conflict. Is there any rule on (C) on net new files in cyrus-sasl ? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc From dwhite at olp.net Mon Apr 13 11:19:05 2020 From: dwhite at olp.net (Dan White) Date: Mon, 13 Apr 2020 10:19:05 -0500 Subject: NTLM authentication not working In-Reply-To: References: Message-ID: <20200413151905.GB983317@olp.net> On 04/11/20?00:53?+0200, Michal Bruncko wrote: >I am trying to use NTLM autentication (using cyrus-sasl-ntlm) for >cyrus-imapd server for user authentication. > >in imapd.conf: > >sasl_ntlm_server:?????? dc1.example.com >sasl_ntlm_v2:?????????? yes >sasl_mech_list:???????? PLAIN NTLM LOGIN > >dc1.example.com is samba 4 AD DC, I have tried also samba 4.2 in NT4 >PDC mode, but with same results. > >in maillog: > >Apr 10 23:32:30 mail cyrus/imaps[10078]: NTLM server step 1 >Apr 10 23:32:30 mail cyrus/imaps[10078]: client flags: ffff8207 >Apr 10 23:32:33 mail cyrus/imaps[10078]: badlogin: >client.example.local [172.17.0.13] NTLM [SASL(0): successful result: ] > >which corresponds to following samba log messages: > >[2020/04/10 23:52:00.583266,? 3] ../source3/smbd/process.c:1880(process_smb) >? Transaction 0 of length 51 (0 toread) >[2020/04/10 23:52:00.583359,? 3] >../source3/smbd/process.c:1489(switch_message) >? switch message SMBnegprot (pid 28556) conn 0x0 >[2020/04/10 23:52:00.586326,? 3] >../source3/smbd/negprot.c:576(reply_negprot) >? Requested protocol [NT LM 0.12] >[2020/04/10 23:52:00.586887,? 3] ../source3/smbd/negprot.c:377(reply_nt1) >? not using SPNEGO >[2020/04/10 23:52:00.586969,? 3] >../source3/smbd/negprot.c:684(reply_negprot) >? Selected protocol NT LM 0.12 >[2020/04/10 23:52:00.591116,? 3] >../source3/smbd/server_exit.c:249(exit_server_common) >? Server exit (failed to receive smb request) Hi Michal, You can increase libsasl's logging with the following in your imapd.conf: sasl_log_level: 7 See: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h for a description of the available log levels. You may need to modify your syslog configuration to accept more verbose auth.* levels. -- Dan White From michal.bruncko at zssos.sk Mon Apr 13 16:23:54 2020 From: michal.bruncko at zssos.sk (Michal Bruncko) Date: Mon, 13 Apr 2020 22:23:54 +0200 Subject: NTLM authentication not working In-Reply-To: <20200413151905.GB983317@olp.net> References: <20200413151905.GB983317@olp.net> Message-ID: Dear Dan thank you for response. followed your proposal with increasing debugging, but for whatever reason it did not produced anything more into syslog. my rsyslog.conf was setup this way (followed by restarting rsyslog daemon) as the first option in list: *.*??????????????????????????????????????????? -/var/log/debug but rather I did strace of imapd daemon and paralel packet capture of communication to samba server. I hope this can be helpful. thanks again michal On 4/13/2020 5:19 PM, Dan White wrote: > On 04/11/20?00:53?+0200, Michal Bruncko wrote: >> I am trying to use NTLM autentication (using cyrus-sasl-ntlm) for >> cyrus-imapd server for user authentication. >> >> in imapd.conf: >> >> sasl_ntlm_server:?????? dc1.example.com >> sasl_ntlm_v2:?????????? yes >> sasl_mech_list:???????? PLAIN NTLM LOGIN >> >> dc1.example.com is samba 4 AD DC, I have tried also samba 4.2 in NT4 >> PDC mode, but with same results. >> >> in maillog: >> >> Apr 10 23:32:30 mail cyrus/imaps[10078]: NTLM server step 1 >> Apr 10 23:32:30 mail cyrus/imaps[10078]: client flags: ffff8207 >> Apr 10 23:32:33 mail cyrus/imaps[10078]: badlogin: >> client.example.local [172.17.0.13] NTLM [SASL(0): successful result: ] >> >> which corresponds to following samba log messages: >> >> [2020/04/10 23:52:00.583266,? 3] >> ../source3/smbd/process.c:1880(process_smb) >> ? Transaction 0 of length 51 (0 toread) >> [2020/04/10 23:52:00.583359,? 3] >> ../source3/smbd/process.c:1489(switch_message) >> ? switch message SMBnegprot (pid 28556) conn 0x0 >> [2020/04/10 23:52:00.586326,? 3] >> ../source3/smbd/negprot.c:576(reply_negprot) >> ? Requested protocol [NT LM 0.12] >> [2020/04/10 23:52:00.586887,? 3] >> ../source3/smbd/negprot.c:377(reply_nt1) >> ? not using SPNEGO >> [2020/04/10 23:52:00.586969,? 3] >> ../source3/smbd/negprot.c:684(reply_negprot) >> ? Selected protocol NT LM 0.12 >> [2020/04/10 23:52:00.591116,? 3] >> ../source3/smbd/server_exit.c:249(exit_server_common) >> ? Server exit (failed to receive smb request) > > Hi Michal, > > You can increase libsasl's logging with the following in your imapd.conf: > > sasl_log_level: 7 > > See: > https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h for > a description of the available log levels. You may need to modify your > syslog configuration to accept more verbose auth.* levels. > -------------- next part -------------- A non-text attachment was scrubbed... Name: imapd.pcap Type: application/octet-stream Size: 1340 bytes Desc: not available URL: -------------- next part -------------- 18268 accept(4, NULL, NULL) = 16 18268 fcntl(15, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0 18268 alarm(0) = 0 18268 getpeername(16, {sa_family=AF_INET, sin_port=htons(58417), sin_addr=inet_addr("172.30.0.103")}, [16]) = 0 18268 getpeername(16, {sa_family=AF_INET, sin_port=htons(58417), sin_addr=inet_addr("172.30.0.103")}, [16]) = 0 18268 getsockname(16, {sa_family=AF_INET, sin_port=htons(143), sin_addr=inet_addr("172.31.0.70")}, [16]) = 0 18268 open("/etc/hosts.allow", O_RDONLY) = 17 18268 fstat(17, {st_mode=S_IFREG|0644, st_size=370, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 read(17, "#\n# hosts.allow\tThis file contains access rules which are used to\n#\t\tallow or deny connections to network services that\n#\t\teithe"..., 4096) = 370 18268 read(17, "", 4096) = 0 18268 close(17) = 0 18268 munmap(0x7fe9e76ea000, 4096) = 0 18268 open("/etc/hosts.deny", O_RDONLY) = 17 18268 fstat(17, {st_mode=S_IFREG|0644, st_size=460, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 read(17, "#\n# hosts.deny\tThis file contains access rules which are used to\n#\t\tdeny connections to network services that either use\n#\t\tthe "..., 4096) = 460 18268 read(17, "", 4096) = 0 18268 close(17) = 0 18268 munmap(0x7fe9e76ea000, 4096) = 0 18268 write(3, "\2\0\0\0\\G\0\0", 8) = 8 18268 dup2(16, 0) = 0 18268 dup2(16, 1) = 1 18268 dup2(16, 2) = 2 18268 close(16) = 0 18268 write(3, "\3\0\0\0\\G\0\0", 8) = 8 18268 getpeername(0, {sa_family=AF_INET, sin_port=htons(58417), sin_addr=inet_addr("172.30.0.103")}, [16]) = 0 18268 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=115, ...}) = 0 18268 open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 16 18268 fstat(16, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 read(16, "multi on\n", 4096) = 9 18268 read(16, "", 4096) = 0 18268 close(16) = 0 18268 munmap(0x7fe9e76ea000, 4096) = 0 18268 futex(0x7fe9e4ffa9f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 18268 open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 16 18268 fstat(16, {st_mode=S_IFREG|0644, st_size=115, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 read(16, "# Generated by NetworkManager\nsearch ad.ssrk.sk ssrk.sk\nnameserver 172.30.0.180\nnameserver 2001:4118:804:f000::180\n", 4096) = 115 18268 read(16, "", 4096) = 0 18268 close(16) = 0 18268 munmap(0x7fe9e76ea000, 4096) = 0 18268 socket(AF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 16 18268 connect(16, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) 18268 close(16) = 0 18268 socket(AF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 16 18268 connect(16, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) 18268 close(16) = 0 18268 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 16 18268 fstat(16, {st_mode=S_IFREG|0644, st_size=1965, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 read(16, "#\n# /etc/nsswitch.conf\n#\n# An example Name Service Switch config file. This file should be\n# sorted with the most-used services "..., 4096) = 1965 18268 read(16, "", 4096) = 0 18268 close(16) = 0 18268 munmap(0x7fe9e76ea000, 4096) = 0 18268 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 16 18268 fstat(16, {st_mode=S_IFREG|0644, st_size=38281, ...}) = 0 18268 mmap(NULL, 38281, PROT_READ, MAP_PRIVATE, 16, 0) = 0x7fe9e7613000 18268 close(16) = 0 18268 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 16 18268 read(16, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000!\0\0\0\0\0\0@\0\0\0\0\0\0\0x\350\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0!\0 \0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(\262\0\0\0\0\0\0(\262\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0"..., 832) = 832 18268 fstat(16, {st_mode=S_IFREG|0755, st_size=61624, ...}) = 0 18268 mmap(NULL, 2173016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 16, 0) = 0x7fe9dfd4a000 18268 mprotect(0x7fe9dfd56000, 2093056, PROT_NONE) = 0 18268 mmap(0x7fe9dff55000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 16, 0xb000) = 0x7fe9dff55000 18268 mmap(0x7fe9dff57000, 22616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe9dff57000 18268 close(16) = 0 18268 mprotect(0x7fe9dff55000, 4096, PROT_READ) = 0 18268 munmap(0x7fe9e7613000, 38281) = 0 18268 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 16 18268 fstat(16, {st_mode=S_IFREG|0644, st_size=183, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 read(16, "127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4\n::1 localhost localhost.localdomain local"..., 4096) = 183 18268 read(16, "", 4096) = 0 18268 close(16) = 0 18268 munmap(0x7fe9e76ea000, 4096) = 0 18268 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 16 18268 fstat(16, {st_mode=S_IFREG|0644, st_size=38281, ...}) = 0 18268 mmap(NULL, 38281, PROT_READ, MAP_PRIVATE, 16, 0) = 0x7fe9e7613000 18268 close(16) = 0 18268 open("/lib64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 16 18268 read(16, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \20\0\0\0\0\0\0@\0\0\0\0\0\0\0pr\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0!\0 \0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0,P\0\0\0\0\0\0,P\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0"..., 832) = 832 18268 fstat(16, {st_mode=S_IFREG|0755, st_size=31408, ...}) = 0 18268 mmap(NULL, 2121952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 16, 0) = 0x7fe9dfb43000 18268 mprotect(0x7fe9dfb49000, 2093056, PROT_NONE) = 0 18268 mmap(0x7fe9dfd48000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 16, 0x5000) = 0x7fe9dfd48000 18268 close(16) = 0 18268 mprotect(0x7fe9dfd48000, 4096, PROT_READ) = 0 18268 munmap(0x7fe9e7613000, 38281) = 0 18268 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 16 18268 connect(16, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.30.0.180")}, 16) = 0 18268 poll([{fd=16, events=POLLOUT}], 1, 0) = 1 ([{fd=16, revents=POLLOUT}]) 18268 sendto(16, "*?\1\0\0\1\0\0\0\0\0\0\003103\0010\00230\003172\7in-addr\4arpa\0\0\f\0\1", 43, MSG_NOSIGNAL, NULL, 0) = 43 18268 poll([{fd=16, events=POLLIN}], 1, 5000) = 1 ([{fd=16, revents=POLLIN}]) 18268 ioctl(16, FIONREAD, [74]) = 0 18268 recvfrom(16, "*?\205\200\0\1\0\1\0\0\0\0\003103\0010\00230\003172\7in-addr\4arpa\0\0\f\0\1\300\f\0\f\0\1\0\0\4\260\0\23\6server\2ad\4ssrk\2sk\0", 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.30.0.180")}, [16]) = 74 18268 close(16) = 0 18268 getsockname(0, {sa_family=AF_INET, sin_port=htons(143), sin_addr=inet_addr("172.31.0.70")}, [16]) = 0 18268 open("/var/lib/imap/proc/18268", O_RDWR|O_CREAT|O_TRUNC, 0666) = 16 18268 fstat(16, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76ea000 18268 lseek(16, 0, SEEK_SET) = 0 18268 write(16, "server.ad.ssrk.sk [172.30.0.103]\n", 33) = 33 18268 lseek(16, 0, SEEK_CUR) = 33 18268 ftruncate(16, 33) = 0 18268 open("/var/lib/imap/msg/motd", O_RDONLY) = -1 ENOENT (No such file or directory) 18268 write(1, "* OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN AUTH=NTLM AUTH=LOGIN AUTH=GSSAPI SASL-IR] mail.ssrk.sk Cyrus I"..., 179) = 179 18268 select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left {1799, 987972}) 18268 select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left {1799, 999996}) 18268 read(0, "1 authenticate NTLM\r\n", 4096) = 21 18268 socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 17 18268 connect(17, {sa_family=AF_INET, sin_port=htons(139), sin_addr=inet_addr("172.30.0.54")}, 16) = 0 18268 writev(17, [{"\201\0\0D", 4}, {" DBDHDCCACACACACACACACACACACACACA\0", 34}, {" ENEBEJEMCACACACACACACACACACACACA\0", 34}], 3) = 72 18268 recvfrom(17, "\202\0\0\0", 4, 0, NULL, NULL) = 4 18268 write(1, "+ \r\n", 4) = 4 18268 select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left {1799, 998186}) 18268 read(0, "TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=\r\n", 4096) = 46 18268 writev(17, [{"\0\0\0/", 4}, {"\377SMBr\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\\G\0\0\0\0", 32}, {"\0", 1}, {"\f\0", 2}, {"\2NT LM 0.12\0", 12}], 5) = 51 18268 recvfrom(17, "\0\0\0g", 4, 0, NULL, NULL) = 4 18268 recvfrom(17, "\377SMBr\0\0\0\0\200\3@\0\0\0\0\0\0\0\0\0\0\0\0\0\0\\G\0\0\0\0\21\0\0\0032\0\1\0\4A\0\0\0\0\1\0\336O\0\0\375\363\200\0008\204L\177\317\21\326\1\210\377\10\"\0=\361d\26\373\376%{Z\0S\0S\0O\0S\0\0\0A\0P\0O\0L\0L\0O\0\0\0", 103, 0, NULL, NULL) = 103 18268 write(1, "+ TlRMTVNTUAACAAAACgAKADAAAAAFggEAPfFkFvv+JXsAAAAAAAAAAAAAAAAAAAAAWgBTAFMATwBTAA==\r\n", 84) = 84 18268 select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left {1798, 48229}) 18268 read(0, "3 authenticate NTLM\r\n", 4096) = 21 18268 open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 18 18268 fstat(18, {st_mode=S_IFREG|0644, st_size=2312, ...}) = 0 18268 fstat(18, {st_mode=S_IFREG|0644, st_size=2312, ...}) = 0 18268 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe9e76e9000 18268 read(18, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\7\0\0\0\0\0\0\0\220\0\0\0\7\0\0\0\r\233\f\27`\233\325\332\360\234\331\256\220\235\244\265\220\236\271\220\220\237\204\227\220\310\tq\220\314\347K\20\315\251\27\220\316\242C\20\317\2224\20\320\202%\20\321r\26\20\321\242\263`\322b\7\20\323\200\34\220\324I\322\20\324\223\264 \325\2r \325L8\20\326)\264\20"..., 4096) = 2312 18268 lseek(18, -1479, SEEK_CUR) = 833 18268 read(18, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0\0\0\0\222\0\0\0\t\0\0\0\25\377\377\377\377\36I\222\370\377\377\377\377l\317\352\370\377\377\377\377\233\f\27`\377\377\377\377\233\325\332\360\377\377\377\377\234\331\256\220\377\377\377\377\235\244\265\220\377\377\377\377\236\271\220\220\377\377\377\377\237\204\227\220\377\377\377\377\310\tq\220\377\377\377\377\314\347K\20\377\377\377\377"..., 4096) = 1479 18268 close(18) = 0 18268 munmap(0x7fe9e76e9000, 4096) = 0 18268 socket(AF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 18 18268 connect(18, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0 18268 sendto(18, "<21>Apr 13 22:09:56 cyrus/imap2[18268]: badlogin: server.ad.ssrk.sk [172.30.0.103] NTLM [SASL(0): successful result: ]", 118, MSG_NOSIGNAL, NULL, 0) = 118 18268 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 18268 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 18268 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 18268 nanosleep({3, 0}, 0x7fff807c2b20) = 0 18268 close(17) = 0 18268 write(1, "1 NO bad protocol / cancel\r\n", 28) = 28 18268 select(1, [0], NULL, NULL, {1797, 0} From michal.bruncko at zssos.sk Mon Apr 13 19:08:38 2020 From: michal.bruncko at zssos.sk (Michal Bruncko) Date: Tue, 14 Apr 2020 01:08:38 +0200 Subject: NTLM authentication not working In-Reply-To: References: <20200413151905.GB983317@olp.net> Message-ID: <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> ok, seems I found the problem. NTLM email client which I am using for testing - Thunderbind - is refusing to finish NTLM authentication because IMAP server is using NTLMv1, which is denied by default Thunderbird configuration. setting up "network.auth.force-generic-ntlm-v1" to "true" makes this authentication finally working. the problem is why NTLMv2 is not used? I found this https://access.redhat.com/solutions/4253821 and recompiled cyrus-sasl with patch enforcing NTLMv2, but seems NTLMv2 is not used neither. then I found out your correspondence here https://lists.andrew.cmu.edu/pipermail/info-cyrus/2010-December/034227.html where you're stating the same, isnt it that? thanks michal On 4/13/2020 10:23 PM, Michal Bruncko wrote: > Dear Dan > > thank you for response. followed your proposal with increasing > debugging, but for whatever reason it did not produced anything more > into syslog. my rsyslog.conf was setup this way (followed by > restarting rsyslog daemon) as the first option in list: > > *.*??????????????????????????????????????????? -/var/log/debug > > but rather I did strace of imapd daemon and paralel packet capture of > communication to samba server. > > I hope this can be helpful. > > thanks again > > michal > > > > On 4/13/2020 5:19 PM, Dan White wrote: >> On 04/11/20?00:53?+0200, Michal Bruncko wrote: >>> I am trying to use NTLM autentication (using cyrus-sasl-ntlm) for >>> cyrus-imapd server for user authentication. >>> >>> in imapd.conf: >>> >>> sasl_ntlm_server:?????? dc1.example.com >>> sasl_ntlm_v2:?????????? yes >>> sasl_mech_list:???????? PLAIN NTLM LOGIN >>> >>> dc1.example.com is samba 4 AD DC, I have tried also samba 4.2 in NT4 >>> PDC mode, but with same results. >>> >>> in maillog: >>> >>> Apr 10 23:32:30 mail cyrus/imaps[10078]: NTLM server step 1 >>> Apr 10 23:32:30 mail cyrus/imaps[10078]: client flags: ffff8207 >>> Apr 10 23:32:33 mail cyrus/imaps[10078]: badlogin: >>> client.example.local [172.17.0.13] NTLM [SASL(0): successful result: ] >>> >>> which corresponds to following samba log messages: >>> >>> [2020/04/10 23:52:00.583266,? 3] >>> ../source3/smbd/process.c:1880(process_smb) >>> ? Transaction 0 of length 51 (0 toread) >>> [2020/04/10 23:52:00.583359,? 3] >>> ../source3/smbd/process.c:1489(switch_message) >>> ? switch message SMBnegprot (pid 28556) conn 0x0 >>> [2020/04/10 23:52:00.586326,? 3] >>> ../source3/smbd/negprot.c:576(reply_negprot) >>> ? Requested protocol [NT LM 0.12] >>> [2020/04/10 23:52:00.586887,? 3] >>> ../source3/smbd/negprot.c:377(reply_nt1) >>> ? not using SPNEGO >>> [2020/04/10 23:52:00.586969,? 3] >>> ../source3/smbd/negprot.c:684(reply_negprot) >>> ? Selected protocol NT LM 0.12 >>> [2020/04/10 23:52:00.591116,? 3] >>> ../source3/smbd/server_exit.c:249(exit_server_common) >>> ? Server exit (failed to receive smb request) >> >> Hi Michal, >> >> You can increase libsasl's logging with the following in your >> imapd.conf: >> >> sasl_log_level: 7 >> >> See: >> https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h for >> a description of the available log levels. You may need to modify your >> syslog configuration to accept more verbose auth.* levels. >> > From alexey.melnikov at isode.com Tue Apr 14 13:35:20 2020 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Tue, 14 Apr 2020 18:35:20 +0100 Subject: License in new files In-Reply-To: References: Message-ID: Hi Simo, On 13/04/2020 15:18, Simo Sorce wrote: > Hello, > In https://github.com/cyrusimap/cyrus-sasl/pull/598 I asked a question > given I forgot to fix (C) in files we recently merged. > > The question is simply: what license needs to be set on files? > I personally prefer to give a very liberal license like 2 clause BSD, > when a non-copyleft work is involved. Generally that license is > compatible with anything else already on the work and won't conflict. > > Is there any rule on (C) on net new files in cyrus-sasl ? I would just cut & paste license from something like plugins/scam.c (and update appropriately): /* ?* Copyright (c) 2009-2016 Carnegie Mellon University.? All rights reserved. ?* ?* Redistribution and use in source and binary forms, with or without ?* modification, are permitted provided that the following conditions ?* are met: ?* ?* 1. Redistributions of source code must retain the above copyright ?*??? notice, this list of conditions and the following disclaimer. ?* ?* 2. Redistributions in binary form must reproduce the above copyright ?*??? notice, this list of conditions and the following disclaimer in ?*??? the documentation and/or other materials provided with the ?*??? distribution. ?* ?* 3. The name "Carnegie Mellon University" must not be used to ?*??? endorse or promote products derived from this software without ?*??? prior written permission. For permission or any other legal ?*??? details, please contact ?*????? Carnegie Mellon University ?*????? Center for Technology Transfer and Enterprise Creation ?*????? 4615 Forbes Avenue ?*????? Suite 302 ?*????? Pittsburgh, PA? 15213 ?*????? (412) 268-7393, fax: (412) 268-7395 ?*????? innovation at andrew.cmu.edu ?* ?* 4. Redistributions of any form whatsoever must retain the following ?*??? acknowledgment: ?*??? "This product includes software developed by Computing Services ?*???? at Carnegie Mellon University (http://www.cmu.edu/computing/)." ?* ?* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO ?* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY ?* AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE ?* FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES ?* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN ?* AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING ?* OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ?*/ I think it is 2 clause BSD. Best Regards, Alexey From simo at redhat.com Tue Apr 14 15:02:58 2020 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Apr 2020 15:02:58 -0400 Subject: License in new files In-Reply-To: References: Message-ID: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> On Tue, 2020-04-14 at 18:35 +0100, Alexey Melnikov wrote: > Hi Simo, > > On 13/04/2020 15:18, Simo Sorce wrote: > > > Hello, > > In https://github.com/cyrusimap/cyrus-sasl/pull/598 I asked a question > > given I forgot to fix (C) in files we recently merged. > > > > The question is simply: what license needs to be set on files? > > I personally prefer to give a very liberal license like 2 clause BSD, > > when a non-copyleft work is involved. Generally that license is > > compatible with anything else already on the work and won't conflict. > > > > Is there any rule on (C) on net new files in cyrus-sasl ? > > I would just cut & paste license from something like plugins/scam.c (and > update appropriately): Unfortunately the text you pasted below is like the original 3-clause bsd + advertising clause which is a bit obnoxious. Plus it list the (C) holder as CMU, which is clearly not the case for software I've written. I could replace the (C) line with my authorship, but still clause 4 would be clumsy in that case, why would I require people to advertise CMU as the author for software that was not authored by CMU ? It'd be much easier if a revised 2 or less clauses BSD was used w/o advertising and (C) was that of the actual authors. If I am allowed to do that for the files *I* contribute I'd be all set. If not it would be nice to have a clear idea of what are the (C) rules for contributions to cyrus-sasl... > /* > * Copyright (c) 2009-2016 Carnegie Mellon University. All rights > reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in > * the documentation and/or other materials provided with the > * distribution. > * > * 3. The name "Carnegie Mellon University" must not be used to > * endorse or promote products derived from this software without > * prior written permission. For permission or any other legal > * details, please contact > * Carnegie Mellon University > * Center for Technology Transfer and Enterprise Creation > * 4615 Forbes Avenue > * Suite 302 > * Pittsburgh, PA 15213 > * (412) 268-7393, fax: (412) 268-7395 > * innovation at andrew.cmu.edu > * > * 4. Redistributions of any form whatsoever must retain the following > * acknowledgment: > * "This product includes software developed by Computing Services > * at Carnegie Mellon University (http://www.cmu.edu/computing/)." > * > * CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO > * THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY > * AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE > * FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING > * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > I think it is 2 clause BSD. > > Best Regards, > > Alexey > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc From michal.bruncko at zssos.sk Tue Apr 14 15:36:55 2020 From: michal.bruncko at zssos.sk (Michal Bruncko) Date: Tue, 14 Apr 2020 21:36:55 +0200 Subject: NTLM authentication not working In-Reply-To: <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> References: <20200413151905.GB983317@olp.net> <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> Message-ID: hello again today I've tried two other options: 1. Dhruva's NTLMv2 patch posted here https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2009-October/001875.html 2. Andrew's Bartlett patch to handover NTLM to winbind (ntlm_auth) Results: 1. the first one seems to be not complete. "unix_timestamp" as used in code snip is not defined elsewhere and therefore I consider it as an customized function. tried to dirty replace that line with "strcpy(timestamp, (char)time(NULL));" but NTLMv2 was not woring neither (thunderbird refused to talk to initiated NTLM negotiation) so I assume the code is not complete. 2. after adjusting patch to centos 7 needs and make it working based on "--with-ntlm_impl=" parameter either ntlm.c (ntlm.h) for "cyrus" or ntlm_samba.*,smb_helper.* for samba implementation it seems this patch really work with using NTLM and untouched Thunderbird NTLM settings with following two drawbacks: - if "log level" in smb.conf is greater than zero, then ntlm_auth tool is producing unsolicited output which is passed by SASL NTLM module to client via IMAP channel. this unexpected output confuses client which then breaks NTLM auth process. with "log level" set to zero, the NTLM works properly. this issue have been encountered only with cyrus-imap. with postfix there was no issue as log output from ntlm_auth have been suppressed by smtpd daemon and not passed to client. - once the authentication is done for example on postfix level durting sending the email, the smtpd daemon segfaults: Apr 14 21:06:19 ms1 postfix/smtpd[28463]: connect from server.local[192.168.11.13] Apr 14 21:06:19 ms1 postfix/smtpd[28463]: interact_helper: Sending 44 bytes do child: YR Tl...AA= Apr 14 21:06:19 ms1 postfix/smtpd[28463]: interact_helper: Got 199 bytes from helper: TT Tl...AA= Apr 14 21:06:19 ms1 postfix/smtpd[28463]: interact_helper: Sending 332 bytes do child: KK Tl...AA= Apr 14 21:06:19 ms1 postfix/smtpd[28463]: interact_helper: Got 9 bytes from helper: AF username Apr 14 21:06:19 ms1 postfix/smtpd[28463]: kill_helper: Helper died with status 0 Apr 14 21:06:20 ms1 postfix/smtpd[28463]: 17D02209DAE: client=server.local[192.168.11.13], sasl_method=NTLM, sasl_username=username at AD.LOCAL Apr 14 21:06:20 ms1 postfix/cleanup[28469]: 17D02209DAE: message-id= Apr 14 21:06:20 ms1 opendkim[1570]: 17D02209DAE: DKIM-Signature field added (s=defaultnew, d=ad.local) Apr 14 21:06:20 ms1 postfix/qmgr[28449]: 17D02209DAE: from=, size=2313, nrcpt=1 (queue active) Apr 14 21:06:20 ms1 kernel: smtpd[28463]: segfault at 55ffffffffff ip 00007f8c9fa07ff4 sp 00007ffdba204b90 error 4 in libc-2.17.so[7f8c9f99a000+1c3000] Apr 14 21:06:20 ms1 postfix/master[28447]: warning: process /usr/libexec/postfix/smtpd pid 28463 killed by signal 11 Apr 14 21:06:20 ms1 postfix/master[28447]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling based on gdb tool it seems that this is related to fclose function during closure within smb_helper.c coming with this patch: (gdb) where #0? 0x00007f030b945ff4 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6 #1? 0x00007f0307b424c9 in kill_helper (helper=0x55bfc70310b0) ??? at smb_helper.c:160 #2? 0x00007f030cb7dc78 in server_dispose (pconn=0x55bfc702d620) at server.c:317 #3? 0x00007f030cb7879b in sasl_dispose (pconn=pconn at entry=0x55bfc702bbb0) ??? at common.c:851 #4? 0x000055bfc6c0741d in xsasl_cyrus_server_free (xp=0x55bfc702bb80) ??? at xsasl_cyrus_server.c:428 #5? 0x000055bfc6bfdf11 in smtpd_sasl_deactivate ( ??? state=state at entry=0x7ffcca507e10) at smtpd_sasl_glue.c:271 #6? 0x000055bfc6bf1034 in smtpd_proto (state=state at entry=0x7ffcca507e10) ??? at smtpd.c:4888 #7? 0x000055bfc6bf1d56 in smtpd_service (stream=, ??? service=0x7ffcca509ed6 "smtps", argv=) at smtpd.c:4962 #8? 0x000055bfc6c00b8a in single_server_wakeup (fd=, attr=0x0) ??? at single_server.c:278 #9? 0x000055bfc6c301b8 in event_loop (delay=) at events.c:1182 #10 0x000055bfc6c01c21 in single_server_main (argc=argc at entry=19, ??? argv=argv at entry=0x7ffcca508938, ??? service=service at entry=0x55bfc6bf1c50 ) ??? at single_server.c:772 #11 0x000055bfc6becc67 in main (argc=19, argv=0x7ffcca508938) at smtpd.c:5459 this sigsegv could be related to this part of code: void kill_helper(struct smb_helper *helper) { ??????? int status; ??????? if ((helper == NULL) || (helper->child_pid == 0)) ??????????????? return; ?????? fclose(helper->pipe_out); ?????? fclose(helper->pipe_in); ??????? waitpid(helper->child_pid, &status, 0); ??????? syslog(LOG_DEBUG, "kill_helper: Helper died with status %d\n", status); ??????? helper->child_pid = 0; ??????? free(helper); } but this is somehow strange as "kill_helper: Helper died with status 0" came into syslog sooner than segfault message of smtpd - which means that both fclose lines have been completed without issues. also I have tried to use conditions in following way: ??????? if (helper->pipe_out != NULL) { ??????????????? fclose(helper->pipe_out); ??????? if (helper->pipe_in != NULL) { ??????????????? fclose(helper->pipe_in); which also did not improve situation... so I am a bit lost here. in sum this patch seems to be the best option now to have a NTLMv2 capability for user authentication, but it has (at least) these two drawbacks... regards michal On 4/14/2020 1:08 AM, Michal Bruncko wrote: > ok, seems I found the problem. NTLM email client which I am using for > testing - Thunderbind - is refusing to finish NTLM authentication > because IMAP server is using NTLMv1, which is denied by default > Thunderbird configuration. setting up > "network.auth.force-generic-ntlm-v1" to "true" makes this > authentication finally working. the problem is why NTLMv2 is not used? > I found this https://access.redhat.com/solutions/4253821 and > recompiled cyrus-sasl with patch enforcing NTLMv2, but seems NTLMv2 is > not used neither. then I found out your correspondence here > https://lists.andrew.cmu.edu/pipermail/info-cyrus/2010-December/034227.html > where you're stating the same, isnt it that? > > thanks > michal > > On 4/13/2020 10:23 PM, Michal Bruncko wrote: >> Dear Dan >> >> thank you for response. followed your proposal with increasing >> debugging, but for whatever reason it did not produced anything more >> into syslog. my rsyslog.conf was setup this way (followed by >> restarting rsyslog daemon) as the first option in list: >> >> *.*??????????????????????????????????????????? -/var/log/debug >> >> but rather I did strace of imapd daemon and paralel packet capture of >> communication to samba server. >> >> I hope this can be helpful. >> >> thanks again >> >> michal >> >> >> >> On 4/13/2020 5:19 PM, Dan White wrote: >>> On 04/11/20?00:53?+0200, Michal Bruncko wrote: >>>> I am trying to use NTLM autentication (using cyrus-sasl-ntlm) for >>>> cyrus-imapd server for user authentication. >>>> >>>> in imapd.conf: >>>> >>>> sasl_ntlm_server:?????? dc1.example.com >>>> sasl_ntlm_v2:?????????? yes >>>> sasl_mech_list:???????? PLAIN NTLM LOGIN >>>> >>>> dc1.example.com is samba 4 AD DC, I have tried also samba 4.2 in >>>> NT4 PDC mode, but with same results. >>>> >>>> in maillog: >>>> >>>> Apr 10 23:32:30 mail cyrus/imaps[10078]: NTLM server step 1 >>>> Apr 10 23:32:30 mail cyrus/imaps[10078]: client flags: ffff8207 >>>> Apr 10 23:32:33 mail cyrus/imaps[10078]: badlogin: >>>> client.example.local [172.17.0.13] NTLM [SASL(0): successful result: ] >>>> >>>> which corresponds to following samba log messages: >>>> >>>> [2020/04/10 23:52:00.583266,? 3] >>>> ../source3/smbd/process.c:1880(process_smb) >>>> ? Transaction 0 of length 51 (0 toread) >>>> [2020/04/10 23:52:00.583359,? 3] >>>> ../source3/smbd/process.c:1489(switch_message) >>>> ? switch message SMBnegprot (pid 28556) conn 0x0 >>>> [2020/04/10 23:52:00.586326,? 3] >>>> ../source3/smbd/negprot.c:576(reply_negprot) >>>> ? Requested protocol [NT LM 0.12] >>>> [2020/04/10 23:52:00.586887,? 3] >>>> ../source3/smbd/negprot.c:377(reply_nt1) >>>> ? not using SPNEGO >>>> [2020/04/10 23:52:00.586969,? 3] >>>> ../source3/smbd/negprot.c:684(reply_negprot) >>>> ? Selected protocol NT LM 0.12 >>>> [2020/04/10 23:52:00.591116,? 3] >>>> ../source3/smbd/server_exit.c:249(exit_server_common) >>>> ? Server exit (failed to receive smb request) >>> >>> Hi Michal, >>> >>> You can increase libsasl's logging with the following in your >>> imapd.conf: >>> >>> sasl_log_level: 7 >>> >>> See: >>> https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h for >>> a description of the available log levels. You may need to modify your >>> syslog configuration to accept more verbose auth.* levels. >>> >> > From quanah at symas.com Tue Apr 14 15:45:04 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 14 Apr 2020 12:45:04 -0700 Subject: License in new files In-Reply-To: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> Message-ID: <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> --On Tuesday, April 14, 2020 4:02 PM -0400 Simo Sorce wrote: > Unfortunately the text you pasted below is like the original 3-clause > bsd + advertising clause which is a bit obnoxious. I think Fastmail or whoever owns the project these days needs to come up with an official policy on: a) What license should be applied b) What requirements (CLA, DCO, etc) there are for accepting large contributions These seem to be currently lacking. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From murch at fastmail.com Tue Apr 14 16:13:18 2020 From: murch at fastmail.com (Ken Murchison) Date: Tue, 14 Apr 2020 16:13:18 -0400 Subject: License in new files In-Reply-To: <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> Message-ID: We are working with CMU to get the project and license released from them and to move it under a more generic license.? Its been a slow process. On 4/14/20 3:45 PM, Quanah Gibson-Mount wrote: > > > --On Tuesday, April 14, 2020 4:02 PM -0400 Simo Sorce > wrote: > >> Unfortunately the text you pasted below is like the original 3-clause >> bsd + advertising clause which is a bit obnoxious. > > I think Fastmail or whoever owns the project these days needs to come > up with an official policy on: > > a) What license should be applied > b) What requirements (CLA, DCO, etc) there are for accepting large > contributions > > These seem to be currently lacking. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > -- Ken Murchison Cyrus Development Team Fastmail US LLC From quanah at symas.com Tue Apr 14 16:16:52 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 14 Apr 2020 13:16:52 -0700 Subject: NTLM authentication not working In-Reply-To: References: <20200413151905.GB983317@olp.net> <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> Message-ID: --On Tuesday, April 14, 2020 10:36 PM +0200 Michal Bruncko wrote: > hello again > > today I've tried two other options: I'd think at this point it'd be best to remove NTLMv1 from cyrus-sasl master, at least, entirely. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From quanah at symas.com Tue Apr 14 16:18:07 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 14 Apr 2020 13:18:07 -0700 Subject: License in new files In-Reply-To: References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> Message-ID: --On Tuesday, April 14, 2020 5:13 PM -0400 Ken Murchison wrote: > We are working with CMU to get the project and license released from them > and to move it under a more generic license.? Its been a slow process. Ok. I can't see master (2.2?) really moving forward much until that's done, so large pieces of work can be integrated w/o issue. What can be done to get CMU engagement improved? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From dave64 at andrew.cmu.edu Tue Apr 14 17:08:45 2020 From: dave64 at andrew.cmu.edu (Dave McMurtrie) Date: Tue, 14 Apr 2020 17:08:45 -0400 (EDT) Subject: License in new files In-Reply-To: References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> Message-ID: On Tue, 14 Apr 2020, Quanah Gibson-Mount wrote: > --On Tuesday, April 14, 2020 5:13 PM -0400 Ken Murchison > wrote: > >> We are working with CMU to get the project and license released from them >> and to move it under a more generic license.? Its been a slow process. > > Ok. I can't see master (2.2?) really moving forward much until that's done, > so large pieces of work can be integrated w/o issue. What can be done to get > CMU engagement improved? I'm trying to keep things moving along. We finally got the website cut over. I have a meeting tomorrow to discuss the license. Thanks! Dave From quanah at symas.com Tue Apr 14 17:40:52 2020 From: quanah at symas.com (Quanah Gibson-Mount) Date: Tue, 14 Apr 2020 14:40:52 -0700 Subject: License in new files In-Reply-To: References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> Message-ID: --On Tuesday, April 14, 2020 6:08 PM -0400 Dave McMurtrie wrote: > I'm trying to keep things moving along. We finally got the website cut > over. I have a meeting tomorrow to discuss the license. > > Thanks! Thank you! :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From michal.bruncko at zssos.sk Tue Apr 14 19:39:11 2020 From: michal.bruncko at zssos.sk (Michal Bruncko) Date: Wed, 15 Apr 2020 01:39:11 +0200 Subject: NTLM authentication not working In-Reply-To: References: <20200413151905.GB983317@olp.net> <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> Message-ID: <4ebadeba-3342-f8e7-21fd-399147c3e54a@zssos.sk> since the NTLMv1 is considered as completely insecure (https://bugzilla.mozilla.org/show_bug.cgi?id=828183) I would agree with that as many applications (incl my case with Mozilla's stuff Thunderbird/Firefox) no longer work natively with NTLMv1 without doing additional config changes (network.auth.force-generic-ntlm-v1 set to TRUE). the question is what will remain in NTLM SASL subtree after removing NTLMv1? Is the existing NTLM SASL implementation fully supporting NTLMv2? I spent some time with debugging this but I wasn't able force NTLM SASL module to provide NTLMv2 between the client and authenticator (SambaAD/PDC) no matter whether I've set "yes" to sasl_ntlm_v2 (imapd.conf) or ntlm_v2 (for postfix) respectively or manually "enforce" NTLMv2 based on patch from https://access.redhat.com/solutions/4253821 . I was always forced to enable ntlm v1 authentication on samba side (ntlm auth = yes) to make the NBT session progressing and not being refused by authenticator. For me the less effort even for future could be with reusing Andrew's patch (https://bugs.gentoo.org/81342) which is handing over this authentication to winbind (ntlm_auth) and which also is the best way to have this NTLM working in future without bigger maintenance efforts. I can share the slightly modifed Andrew's patch which can be easily applied against rhel/centos 7 if anybody is interested. as I wrote before it has still some drawbacks which I hope can be even easily managed by programmers (not my case) and used in upstream (at least) as an alternative to current state. patch provides switch - which engine has to be used for NTLM authentication - either cyrus (existing ntlm.c) or samba (ntlm_samba.c, smb_helper.c) - and compiled into libntlm.so. Patch introduces also new module GSSSPNEGO (MS Kerberos method) but this was not tested as the existing GSSAPI SASL module works well for us. regards michal On 4/14/2020 10:16 PM, Quanah Gibson-Mount wrote: > > > --On Tuesday, April 14, 2020 10:36 PM +0200 Michal Bruncko > wrote: > >> hello again >> >> today I've tried two other options: > > I'd think at this point it'd be best to remove NTLMv1 from cyrus-sasl > master, at least, entirely. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > From ellie at fastmail.com Tue Apr 14 20:24:57 2020 From: ellie at fastmail.com (ellie timoney) Date: Wed, 15 Apr 2020 10:24:57 +1000 Subject: License in new files In-Reply-To: References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> Message-ID: It's worth observing that the only reason we're even ABLE to consider moving away from the 4-clause BSD licence is because all copyrights from all contributors have historically been assigned to a single entity (CMU), who can then choose to transfer ownership or relicense if they desire. If we had had a historical practice of letting individual contributors add their own copyright to individual contributions, even under the same 4-clause licence, this would require chasing approval dozens of individual copyright holders (who might not be contactable or might no longer exist), and it would probably never happen. Whatever license we end up going with, and wherever the existing copyright assignment ends up landing (if it gets transferred), I kinda think we should maintain the same practice of requiring contributions to assign copyright to the single entity. I'm not a lawyer, and I don't pay a lot of attention to the minutiae of open source project licensing (because I don't have to, because it's all assigned to CMU and all using the same licence!). There's probably good examples out there of big projects that allow individual copyrights. But the other factor to think about is -- do we have the resources to manage the administrative overhead introduced by such a scheme? My gut feel says no: including both regular cyrus-imap and cyrus-sasl contributors, we're what, a dozen people tops? I think it would be naive to assume we're never going to need to relicense ever again (after all, 4-clause BSD seemed like a good idea once upon a time), so let's not make things hard on our future selves. Cheers, ellie From simo at redhat.com Wed Apr 15 09:24:54 2020 From: simo at redhat.com (Simo Sorce) Date: Wed, 15 Apr 2020 09:24:54 -0400 Subject: License in new files In-Reply-To: References: <3b71da98bd1c16f61d63b6460d16478b8be77973.camel@redhat.com> <4F8743AEC42BAF0018FEBF29@[192.168.1.144]> Message-ID: <26e2002340bcd86765020127fabe391140dd0b0e.camel@redhat.com> Hi Ellie, On Wed, 2020-04-15 at 10:24 +1000, ellie timoney wrote: > It's worth observing that the only reason we're even ABLE to consider > moving away from the 4-clause BSD licence is because all copyrights > from all contributors have historically been assigned to a single > entity (CMU), who can then choose to transfer ownership or relicense > if they desire. Keep in mind that with a liberal license like the current one, you can always move to a different overall license. Original contributions won't be changed without owner's permission, but you can simply switch to use a new license for any new contribution. The situation is not as dire as it may seem. And it is not as complicated as changing the license on a copyleft project where you have to change it all at once or do nothing. The 4th clause is annoying, and generally will probably be violated, unintentionally of course, in most settings. So it is worth avoiding it simply because it places an undue burden that is not reasonable in this day and age where you may be using literally thousands of works in a single piece of software delivered to a final user. > If we had had a historical practice of letting individual > contributors add their own copyright to individual contributions, > even under the same 4-clause licence, this would require chasing > approval dozens of individual copyright holders (who might not be > contactable or might no longer exist), and it would probably never > happen. > > Whatever license we end up going with, and wherever the existing > copyright assignment ends up landing (if it gets transferred), I > kinda think we should maintain the same practice of requiring > contributions to assign copyright to the single entity. I hear this argument a lot lately, and I really do not buy it. I have been historically quite adverse to CLAs (I had a talk at FOSDEM, in the legal room, against them a few years ago, for example), and Copyright assignment in general due to personal experiences. It is a high barrier to entry and doesn't really give the benefit you think except when you have a bad license to start with, OR you want to have the ability to take the code private and shunt your community. There are very successful projects that do not need CA as evidence, these are not just my words. For high visibility and well funded/marketed projects, people do jump through hoops in order to participate. But I have been in lower key projects were contributors simply walked away because it was too hard for them to obtain any sort of legal approval for (C) transfer/CLA signing, or it was simply too much of a pain to do so. Using an inbound/outbound process is generally much better suited for drive-by contributions like cyrus-sasl generally receives. I suggest you read this link if you want the perspective of a lawyer: https://opensource.com/article/19/2/cla-problems > I'm not a lawyer, and I don't pay a lot of attention to the minutiae > of open source project licensing (because I don't have to, because > it's all assigned to CMU and all using the same licence!). There's > probably good examples out there of big projects that allow > individual copyrights. But the other factor to think about is -- do > we have the resources to manage the administrative overhead > introduced by such a scheme? My gut feel says no: including both > regular cyrus-imap and cyrus-sasl contributors, we're what, a dozen > people tops? Exactly, CLAs or Copyright assignment cause a ton of overhead. A license that does not make one entity "more important" than the other contributors (like the current license somewhat does in clause 4) is a much smoother ride. Sure you have multiple (C) ownership, but it is a liberal license, so in general there will be no problem at all. > I think it would be naive to assume we're never going to need to > relicense ever again (after all, 4-clause BSD seemed like a good idea > once upon a time), so let's not make things hard on our future > selves. It *may* happen, but it is also a very rare thing, does it make sense to optimize for once-in-a-lifetime events? Or is it better to optimize for lowest overhead all the time and leave a little pain concentrated in one event if and when it happens? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc From simo at redhat.com Wed Apr 15 09:38:14 2020 From: simo at redhat.com (Simo Sorce) Date: Wed, 15 Apr 2020 09:38:14 -0400 Subject: NTLM authentication not working In-Reply-To: <4ebadeba-3342-f8e7-21fd-399147c3e54a@zssos.sk> References: <20200413151905.GB983317@olp.net> <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> <4ebadeba-3342-f8e7-21fd-399147c3e54a@zssos.sk> Message-ID: Hi Michal, I have a fully working implementation of NTLM, that follows Microsoft's spec faithfully and with proper testing, and also allow to configure what is allowed and what isn't. It is implemented as a GSSAPI module called GSSNTLMSSP: https://github.com/gssapi/gss-ntlmssp We can simply remove NTLM code entirely and just write a wrapper that will use GSSNTLMSSP instead. This will relieve Cyrus-sasl from the need to deal with this old broken protocol and defer it to an external party, at the same time gaining a more tested, and better working implementation. Note that GSSNTLMSSP also provide a few advantages to users as it can be integrated with Winbind and potentially other backends on a server so that authentication will work in a Windows Domain w/o the need to host lists of passwords for users on the individual servers. I would avoid ntlm_auth (I am an historical Samba Team member so I know it well), simply because it will remove features, namely that you won't be able to just have a simple list of passwords on a system w/o having to install all of samba and make it run. For small setup that's really overkill. Finally, we already have GSS-SPNEGO in SASL so not sure what you mean at the end of your message here. Note that GSSAPI will fallback to use GSSNTLMSSP *already* within SPNEGO if available on the system (we used that in mod_auth_gssapi all the time for example, as well as in Firefox actually), although I haven't checked if cyrus-sasl code will work correctly in that case yet. Simo. On Wed, 2020-04-15 at 01:39 +0200, Michal Bruncko wrote: > since the NTLMv1 is considered as completely insecure > (https://bugzilla.mozilla.org/show_bug.cgi?id=828183) I would agree with > that as many applications (incl my case with Mozilla's stuff > Thunderbird/Firefox) no longer work natively with NTLMv1 without doing > additional config changes (network.auth.force-generic-ntlm-v1 set to TRUE). > the question is what will remain in NTLM SASL subtree after removing > NTLMv1? Is the existing NTLM SASL implementation fully supporting > NTLMv2? I spent some time with debugging this but I wasn't able force > NTLM SASL module to provide NTLMv2 between the client and authenticator > (SambaAD/PDC) no matter whether I've set "yes" to sasl_ntlm_v2 > (imapd.conf) or ntlm_v2 (for postfix) respectively or manually "enforce" > NTLMv2 based on patch from https://access.redhat.com/solutions/4253821 . > I was always forced to enable ntlm v1 authentication on samba side (ntlm > auth = yes) to make the NBT session progressing and not being refused by > authenticator. > For me the less effort even for future could be with reusing Andrew's > patch (https://bugs.gentoo.org/81342) which is handing over this > authentication to winbind (ntlm_auth) and which also is the best way to > have this NTLM working in future without bigger maintenance efforts. I > can share the slightly modifed Andrew's patch which can be easily > applied against rhel/centos 7 if anybody is interested. as I wrote > before it has still some drawbacks which I hope can be even easily > managed by programmers (not my case) and used in upstream (at least) as > an alternative to current state. patch provides switch - which engine > has to be used for NTLM authentication - either cyrus (existing ntlm.c) > or samba (ntlm_samba.c, smb_helper.c) - and compiled into libntlm.so. > Patch introduces also new module GSSSPNEGO (MS Kerberos method) but this > was not tested as the existing GSSAPI SASL module works well for us. > > regards > michal > > > On 4/14/2020 10:16 PM, Quanah Gibson-Mount wrote: > > > > --On Tuesday, April 14, 2020 10:36 PM +0200 Michal Bruncko > > wrote: > > > > > hello again > > > > > > today I've tried two other options: > > > > I'd think at this point it'd be best to remove NTLMv1 from cyrus-sasl > > master, at least, entirely. > > > > --Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc From rick at openfortress.nl Thu Apr 16 03:33:11 2020 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 16 Apr 2020 09:33:11 +0200 Subject: Finding a mechanism plugin Message-ID: <5E980A37.6070408@openfortress.nl> Hello, I am developing a plugin library that is built outside of the Cyrus SASL package, so using its -dev but not its source. To test from the build environment (as is typical under CMake) the system-installed libsasl2.so needs to see my libhaan.so plugin library. Is that somehow supported, like with an envvar? -Rick From michal.bruncko at zssos.sk Thu Apr 16 06:30:33 2020 From: michal.bruncko at zssos.sk (Michal Bruncko) Date: Thu, 16 Apr 2020 12:30:33 +0200 Subject: NTLM authentication not working In-Reply-To: References: <20200413151905.GB983317@olp.net> <357a310c-5726-7053-deb6-51f734c61e93@zssos.sk> <4ebadeba-3342-f8e7-21fd-399147c3e54a@zssos.sk> Message-ID: Hello Simo even better approach! thanks for your response. I agree with fact that ntlm_auth requires samba layer installed on same system which could be unneccessary if its required just for doing NTLM. > Finally, we already have GSS-SPNEGO in SASL so not sure what you mean at the end of your message here. Andrew's patch (https://bugs.gentoo.org/81342) contains support for this mechanism in form of new module for SASL named "GSSSPNEGO" which again uses Samba layer to make it work. But again, this is not important. In sum from usage perspective any improvement intiative for NTLM plugin would be better than existing state with only NTLMv1 support. regards michal On 4/15/2020 3:38 PM, Simo Sorce wrote: > Hi Michal, > I have a fully working implementation of NTLM, that follows Microsoft's > spec faithfully and with proper testing, and also allow to configure > what is allowed and what isn't. > It is implemented as a GSSAPI module called GSSNTLMSSP: > https://github.com/gssapi/gss-ntlmssp > > We can simply remove NTLM code entirely and just write a wrapper that > will use GSSNTLMSSP instead. This will relieve Cyrus-sasl from the need > to deal with this old broken protocol and defer it to an external > party, at the same time gaining a more tested, and better working > implementation. > > Note that GSSNTLMSSP also provide a few advantages to users as it can > be integrated with Winbind and potentially other backends on a server > so that authentication will work in a Windows Domain w/o the need to > host lists of passwords for users on the individual servers. > > I would avoid ntlm_auth (I am an historical Samba Team member so I know > it well), simply because it will remove features, namely that you won't > be able to just have a simple list of passwords on a system w/o having > to install all of samba and make it run. For small setup that's really > overkill. > > Finally, we already have GSS-SPNEGO in SASL so not sure what you mean > at the end of your message here. > Note that GSSAPI will fallback to use GSSNTLMSSP *already* within > SPNEGO if available on the system (we used that in mod_auth_gssapi all > the time for example, as well as in Firefox actually), although I > haven't checked if cyrus-sasl code will work correctly in that case > yet. > > Simo. > > On Wed, 2020-04-15 at 01:39 +0200, Michal Bruncko wrote: >> since the NTLMv1 is considered as completely insecure >> (https://bugzilla.mozilla.org/show_bug.cgi?id=828183) I would agree with >> that as many applications (incl my case with Mozilla's stuff >> Thunderbird/Firefox) no longer work natively with NTLMv1 without doing >> additional config changes (network.auth.force-generic-ntlm-v1 set to TRUE). >> the question is what will remain in NTLM SASL subtree after removing >> NTLMv1? Is the existing NTLM SASL implementation fully supporting >> NTLMv2? I spent some time with debugging this but I wasn't able force >> NTLM SASL module to provide NTLMv2 between the client and authenticator >> (SambaAD/PDC) no matter whether I've set "yes" to sasl_ntlm_v2 >> (imapd.conf) or ntlm_v2 (for postfix) respectively or manually "enforce" >> NTLMv2 based on patch from https://access.redhat.com/solutions/4253821 . >> I was always forced to enable ntlm v1 authentication on samba side (ntlm >> auth = yes) to make the NBT session progressing and not being refused by >> authenticator. >> For me the less effort even for future could be with reusing Andrew's >> patch (https://bugs.gentoo.org/81342) which is handing over this >> authentication to winbind (ntlm_auth) and which also is the best way to >> have this NTLM working in future without bigger maintenance efforts. I >> can share the slightly modifed Andrew's patch which can be easily >> applied against rhel/centos 7 if anybody is interested. as I wrote >> before it has still some drawbacks which I hope can be even easily >> managed by programmers (not my case) and used in upstream (at least) as >> an alternative to current state. patch provides switch - which engine >> has to be used for NTLM authentication - either cyrus (existing ntlm.c) >> or samba (ntlm_samba.c, smb_helper.c) - and compiled into libntlm.so. >> Patch introduces also new module GSSSPNEGO (MS Kerberos method) but this >> was not tested as the existing GSSAPI SASL module works well for us. >> >> regards >> michal >> >> >> On 4/14/2020 10:16 PM, Quanah Gibson-Mount wrote: >>> --On Tuesday, April 14, 2020 10:36 PM +0200 Michal Bruncko >>> wrote: >>> >>>> hello again >>>> >>>> today I've tried two other options: >>> I'd think at this point it'd be best to remove NTLMv1 from cyrus-sasl >>> master, at least, entirely. >>> >>> --Quanah >>> >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Product Architect >>> Symas Corporation >>> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >>> From rick at openfortress.nl Thu Apr 16 10:21:17 2020 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 16 Apr 2020 16:21:17 +0200 Subject: Finding a mechanism plugin In-Reply-To: <20200416140038.GA1086667@olp.net> References: <5E980A37.6070408@openfortress.nl> <20200416140038.GA1086667@olp.net> Message-ID: <5E9869DD.5040900@openfortress.nl> Thanks Dan, > The path can be overridden using the SASL_PATH environment variable. See > sasl_getpath_t(3). Just what I needed -- I didn't know that SASL_PATH was also used to load the libraries. The other stuff is in the "make install" already, but I would rather test before making a system potentially unstable ;-) -Rick From bandaru.v at pg.com Mon Apr 27 15:06:35 2020 From: bandaru.v at pg.com (Bandaru, Vamsi) Date: Mon, 27 Apr 2020 19:06:35 +0000 Subject: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . Message-ID: Hi all , ( This is my first post here ) , I am trying to use Cyrus SASL for SMTP authentication against my organization's LDAP server . I have two major issues I noticed : The auth.log under /var/log reads : Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The message logs read : saslauthd[85790]: detach_tty : could not lock pid file /run/saslauthd/saslauthd.pid: Resource temporarily unavailable saslauthd[85789]: detach_tty : Cannot start saslauthd saslauthd[85789]: detach_tty : Another instance of saslauthd is currently running These are the files , and their locations I am trying to configure . ( am I missing any other files to configure ) 1. /etc/saslauthd.conf 2. /etc/sasl2/smtpd.conf My /etc/saslauthd.conf , is configured in the following way : ldap_servers: ldaps://< hostname >:636 ldap_bind_dn: uid=xxx,ou=xx,ou=xx,o=xx ldap_bind_pw: xxxx ldap_version: 3 ldap_auth_method: bind ldap_search_base: ou=xx,ou=ss,o=xx ldap_scope: sub ldap_filter: ShortName=%U *********************************************************************** The /etc/sasl2/smtpd.conf is configured as : pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 **************************************************************** #ldapdb_mech: LOGIN ( I am not sure if this parameter should be configured under smtpd.conf or under saslauthd.conf ) Output of : saslauthd -a ldap -O /etc/saslauthd.conf # saslauthd -a ldap -O /etc/saslauthd.conf saslauthd[91048] :detach_tty : Cannot start saslauthd saslauthd[91048] :detach_tty : Another instance of saslauthd is currently running * # ps aux | grep saslauthd * root 84395 0.0 0.0 74456 956 ? Ss 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84396 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84397 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84398 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84399 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r SASL related configuration under postfix / main.cf file . smtpd_sasl_auth_enable = yes smtpd_sasl_type = cyrus smtpd_sasl_path = /run/saslauthd/mux #smtpd_sasl_path = /usr/lib64/sasl2 smtpd_sasl_security_options = noanonymous smtpd_tls_auth_only = yes smtpd_sasl_tls_security_options = noanonymous ******************************************************************************* Could someone please help me if these are the only two files that requires configuration to get SASL working ? 1. /etc/saslauthd.conf 2. /etc/sasl2/smtpd.conf And if I have got their configuration right . And these are the packages I currently installed on my RHEL 7 system : cyrus-sasl-2.1.26-23.el7.x86_64 cyrus-sasl-devel-2.1.26-23.el7.x86_64 cyrus-sasl-ldap-2.1.26-23.el7.x86_64 cyrus-sasl-md5-2.1.26-23.el7.x86_64 cyrus-sasl-ntlm-2.1.26-23.el7.x86_64 cyrus-sasl-plain-2.1.26-23.el7.x86_64 cyrus-sasl-lib-2.1.26-23.el7.x86_64 Any help / suggests are greatly appreciated . Thanks and regards, Vamsi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bandaru.v at pg.com Mon Apr 27 16:22:11 2020 From: bandaru.v at pg.com (Bandaru, Vamsi) Date: Mon, 27 Apr 2020 20:22:11 +0000 Subject: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . In-Reply-To: References: Message-ID: Adding the output of pluginviewer : ldapdb is not listed as a one of the auxprop mechanisms : # /usr/sbin/pluginviewer -a Installed and properly configured auxprop mechanisms are: sasldb List of auxprop plugins follows Plugin "sasldb" , API version: 8 supports store: yes and I don't have a pluginviewer.conf on my system , another conf file I have is : /etc/sasl2/slapd.conf # cat /etc/sasl2/slapd.conf mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux ( this doesn't look right ) Regards, From: Cyrus-sasl On Behalf Of Bandaru, Vamsi Sent: Tuesday, April 28, 2020 12:37 AM To: cyrus-sasl at lists.andrew.cmu.edu Subject: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . CAUTION: This email originated outside P&G. Please exercise caution when opening any links or attachments. Hi all , ( This is my first post here ) , I am trying to use Cyrus SASL for SMTP authentication against my organization's LDAP server . I have two major issues I noticed : The auth.log under /var/log reads : Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb The message logs read : saslauthd[85790]: detach_tty : could not lock pid file /run/saslauthd/saslauthd.pid: Resource temporarily unavailable saslauthd[85789]: detach_tty : Cannot start saslauthd saslauthd[85789]: detach_tty : Another instance of saslauthd is currently running These are the files , and their locations I am trying to configure . ( am I missing any other files to configure ) 1. /etc/saslauthd.conf 2. /etc/sasl2/smtpd.conf My /etc/saslauthd.conf , is configured in the following way : ldap_servers: ldaps://< hostname >:636 ldap_bind_dn: uid=xxx,ou=xx,ou=xx,o=xx ldap_bind_pw: xxxx ldap_version: 3 ldap_auth_method: bind ldap_search_base: ou=xx,ou=ss,o=xx ldap_scope: sub ldap_filter: ShortName=%U *********************************************************************** The /etc/sasl2/smtpd.conf is configured as : pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 **************************************************************** #ldapdb_mech: LOGIN ( I am not sure if this parameter should be configured under smtpd.conf or under saslauthd.conf ) Output of : saslauthd -a ldap -O /etc/saslauthd.conf # saslauthd -a ldap -O /etc/saslauthd.conf saslauthd[91048] :detach_tty : Cannot start saslauthd saslauthd[91048] :detach_tty : Another instance of saslauthd is currently running * # ps aux | grep saslauthd * root 84395 0.0 0.0 74456 956 ? Ss 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84396 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84397 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84398 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r * root 84399 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r SASL related configuration under postfix / main.cf file . smtpd_sasl_auth_enable = yes smtpd_sasl_type = cyrus smtpd_sasl_path = /run/saslauthd/mux #smtpd_sasl_path = /usr/lib64/sasl2 smtpd_sasl_security_options = noanonymous smtpd_tls_auth_only = yes smtpd_sasl_tls_security_options = noanonymous ******************************************************************************* Could someone please help me if these are the only two files that requires configuration to get SASL working ? 1. /etc/saslauthd.conf 2. /etc/sasl2/smtpd.conf And if I have got their configuration right . And these are the packages I currently installed on my RHEL 7 system : cyrus-sasl-2.1.26-23.el7.x86_64 cyrus-sasl-devel-2.1.26-23.el7.x86_64 cyrus-sasl-ldap-2.1.26-23.el7.x86_64 cyrus-sasl-md5-2.1.26-23.el7.x86_64 cyrus-sasl-ntlm-2.1.26-23.el7.x86_64 cyrus-sasl-plain-2.1.26-23.el7.x86_64 cyrus-sasl-lib-2.1.26-23.el7.x86_64 Any help / suggests are greatly appreciated . Thanks and regards, Vamsi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad+lists at uni-x.org Mon Apr 27 17:47:22 2020 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Mon, 27 Apr 2020 23:47:22 +0200 Subject: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . In-Reply-To: References: Message-ID: <32e9cb82-1586-ee4d-d483-fc3fb05bc1a9@uni-x.org> Am 27.04.2020 um 21:06 schrieb Bandaru, Vamsi: > > Hi all , > > ( This is my first post here ) , > > I am trying to use Cyrus SASL for SMTP authentication against my organization's LDAP server . > > I have two major issues I noticed : > > The auth.log under /var/log reads : > > Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb > Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb > > The message logs read : > > saslauthd[85790]: detach_tty : could not lock pid file /run/saslauthd/saslauthd.pid: Resource temporarily unavailable > saslauthd[85789]: detach_tty : Cannot start saslauthd > saslauthd[85789]: detach_tty : Another instance of saslauthd is currently running > > > These are the files , and their locations I am trying to configure . ( am I missing any other files to configure ) > > > 1. /etc/saslauthd.conf > 2. /etc/sasl2/smtpd.conf > > > My /etc/saslauthd.conf , is configured in the following way : > > ldap_servers: ldaps://< hostname >:636 > ldap_bind_dn: uid=xxx,ou=xx,ou=xx,o=xx > ldap_bind_pw: xxxx > > ldap_version: 3 > ldap_auth_method: bind > ldap_search_base: ou=xx,ou=ss,o=xx > ldap_scope: sub > ldap_filter: ShortName=%U > > *********************************************************************** > > The /etc/sasl2/smtpd.conf is configured as : > > pwcheck_method: auxprop > auxprop_plugin: ldapdb > > mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 > > **************************************************************** > > #ldapdb_mech: LOGIN ( I am not sure if this parameter should be configured under smtpd.conf or under saslauthd.conf ) > > > > Output of : saslauthd -a ldap -O /etc/saslauthd.conf > > # saslauthd -a ldap -O /etc/saslauthd.conf > saslauthd[91048] :detach_tty : Cannot start saslauthd > saslauthd[91048] :detach_tty : Another instance of saslauthd is currently running > > > > * # ps aux | grep saslauthd > * root 84395 0.0 0.0 74456 956 ? Ss 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84396 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84397 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84398 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84399 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > > > SASL related configuration under postfix / main.cf file . > > smtpd_sasl_auth_enable = yes > smtpd_sasl_type = cyrus > > smtpd_sasl_path = /run/saslauthd/mux > > #smtpd_sasl_path = /usr/lib64/sasl2 > smtpd_sasl_security_options = noanonymous > smtpd_tls_auth_only = yes > smtpd_sasl_tls_security_options = noanonymous > > > ******************************************************************************* > > > Could someone please help me if these are the only two files that requires configuration to get SASL working ? > > > 1. /etc/saslauthd.conf > 2. /etc/sasl2/smtpd.conf > > > And if I have got their configuration right . > > And these are the packages I currently installed on my RHEL 7 system : > > cyrus-sasl-2.1.26-23.el7.x86_64 > cyrus-sasl-devel-2.1.26-23.el7.x86_64 > cyrus-sasl-ldap-2.1.26-23.el7.x86_64 > cyrus-sasl-md5-2.1.26-23.el7.x86_64 > cyrus-sasl-ntlm-2.1.26-23.el7.x86_64 > cyrus-sasl-plain-2.1.26-23.el7.x86_64 > cyrus-sasl-lib-2.1.26-23.el7.x86_64 > > > Any help / suggests are greatly appreciated . > > > Thanks and regards, Vamsi. Hi, you are mixing 2 options to configure cyrus-sasl with LDAP as the backend, both are exclusive. With other words: either use saslauthd and forget about auxprop with ldapdb or the other way around. If you opt fo cyrus SASL with ldapdb then check closely the man page: https://blog.sys4.de/cyrus-sasl-ldapdb-man-page-en.html The option will have to be defined inb /etc/sasl2/smtpd.conf. Regards, Alexander From bandaru.v at pg.com Mon Apr 27 18:23:30 2020 From: bandaru.v at pg.com (Bandaru, Vamsi) Date: Mon, 27 Apr 2020 22:23:30 +0000 Subject: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . In-Reply-To: <32e9cb82-1586-ee4d-d483-fc3fb05bc1a9@uni-x.org> References: <32e9cb82-1586-ee4d-d483-fc3fb05bc1a9@uni-x.org> Message-ID: Thank you , I have emptied the /etc/saslauthd.conf file and moved all the configuration to /etc/sasl2/smtpd.conf ************************************************************ pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 ldap_servers: ldaps://xx.xx.xx.:636 ldap_bind_dn: uid=xx,ou=xx,ou=xx,o=xx ldap_bind_pw: xxxxxxx ldap_version: 3 ldap_auth_method: bind ldap_search_base: ou=xx,ou=xx,o=xx ldap_scope: sub ldap_filter: ShortName=%U ldap_mech: DIGEST-MD5 ************************************************************ Any recommended ways to test if this is working ? ( I continue to have similar errors in my logs ) # /usr/sbin/pluginviewer -a >> doesn't list ldapdb . Installed and properly configured auxprop mechanisms are: sasldb List of auxprop plugins follows Plugin "sasldb" , API version: 8 supports store: yes ****************************************************************** In the meanwhile I will try uninstalling the s/w reinstalling all the cyrus sasl plugins and then configuring them again . Regards, Vamsi. -----Original Message----- From: Cyrus-sasl On Behalf Of Alexander Dalloz Sent: Tuesday, April 28, 2020 3:17 AM To: cyrus-sasl at lists.andrew.cmu.edu Subject: Re: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . CAUTION: This email originated outside P&G. Please exercise caution when opening any links or attachments. Am 27.04.2020 um 21:06 schrieb Bandaru, Vamsi: > > Hi all , > > ( This is my first post here ) , > > I am trying to use Cyrus SASL for SMTP authentication against my organization's LDAP server . > > I have two major issues I noticed : > > The auth.log under /var/log reads : > > Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: > _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb > Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: > _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb > > The message logs read : > > saslauthd[85790]: detach_tty : could not lock pid file /run/saslauthd/saslauthd.pid: Resource temporarily unavailable > saslauthd[85789]: detach_tty : Cannot start saslauthd > saslauthd[85789]: detach_tty : Another instance of saslauthd is currently running > > > These are the files , and their locations I am trying to configure . ( > am I missing any other files to configure ) > > > 1. /etc/saslauthd.conf > 2. /etc/sasl2/smtpd.conf > > > My /etc/saslauthd.conf , is configured in the following way : > > ldap_servers: ldaps://< hostname >:636 > ldap_bind_dn: uid=xxx,ou=xx,ou=xx,o=xx > ldap_bind_pw: xxxx > > ldap_version: 3 > ldap_auth_method: bind > ldap_search_base: ou=xx,ou=ss,o=xx > ldap_scope: sub > ldap_filter: ShortName=%U > > ********************************************************************** > * > > The /etc/sasl2/smtpd.conf is configured as : > > pwcheck_method: auxprop > auxprop_plugin: ldapdb > > mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 > > **************************************************************** > > #ldapdb_mech: LOGIN ( I am not sure if this parameter should be configured under smtpd.conf or under saslauthd.conf ) > > > > Output of : saslauthd -a ldap -O /etc/saslauthd.conf > > # saslauthd -a ldap -O /etc/saslauthd.conf > saslauthd[91048] :detach_tty : Cannot start saslauthd > saslauthd[91048] :detach_tty : Another instance of saslauthd is currently running > > > > * # ps aux | grep saslauthd > * root 84395 0.0 0.0 74456 956 ? Ss 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84396 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84397 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84398 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84399 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > > > SASL related configuration under postfix / main.cf file . > > smtpd_sasl_auth_enable = yes > smtpd_sasl_type = cyrus > > smtpd_sasl_path = /run/saslauthd/mux > > #smtpd_sasl_path = /usr/lib64/sasl2 > smtpd_sasl_security_options = noanonymous smtpd_tls_auth_only = yes > smtpd_sasl_tls_security_options = noanonymous > > > ********************************************************************** > ********* > > > Could someone please help me if these are the only two files that requires configuration to get SASL working ? > > > 1. /etc/saslauthd.conf > 2. /etc/sasl2/smtpd.conf > > > And if I have got their configuration right . > > And these are the packages I currently installed on my RHEL 7 system : > > cyrus-sasl-2.1.26-23.el7.x86_64 > cyrus-sasl-devel-2.1.26-23.el7.x86_64 > cyrus-sasl-ldap-2.1.26-23.el7.x86_64 > cyrus-sasl-md5-2.1.26-23.el7.x86_64 > cyrus-sasl-ntlm-2.1.26-23.el7.x86_64 > cyrus-sasl-plain-2.1.26-23.el7.x86_64 > cyrus-sasl-lib-2.1.26-23.el7.x86_64 > > > Any help / suggests are greatly appreciated . > > > Thanks and regards, Vamsi. Hi, you are mixing 2 options to configure cyrus-sasl with LDAP as the backend, both are exclusive. With other words: either use saslauthd and forget about auxprop with ldapdb or the other way around. If you opt fo cyrus SASL with ldapdb then check closely the man page: https://blog.sys4.de/cyrus-sasl-ldapdb-man-page-en.html The option will have to be defined inb /etc/sasl2/smtpd.conf. Regards, Alexander From whitehse at gmail.com Tue Apr 28 11:21:17 2020 From: whitehse at gmail.com (Dan White) Date: Tue, 28 Apr 2020 10:21:17 -0500 Subject: Unable to load the ldapdb plugin -- during SMTP AUTH against LDAP server . In-Reply-To: References: Message-ID: <20200428152117.GA138537@dan.olp.net> Hi Vamsi, Comments are inline below. >From: Cyrus-sasl On Behalf Of Bandaru, Vamsi >Sent: Tuesday, April 28, 2020 12:37 AM > >Hi all , > >( This is my first post here ) , > >I am trying to use Cyrus SASL for SMTP authentication against my organization's LDAP server . > >I have two major issues I noticed : > >The auth.log under /var/log reads : > >Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb >Apr 27 14:57:36 postfix-in-1/submission/smtpd[42282]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb > >The message logs read : > >saslauthd[85790]: detach_tty : could not lock pid file /run/saslauthd/saslauthd.pid: Resource temporarily unavailable >saslauthd[85789]: detach_tty : Cannot start saslauthd >saslauthd[85789]: detach_tty : Another instance of saslauthd is currently running As Alexander mentioned, there are two different concepts getting mixed up here. See: https://www.cyrusimap.org/sasl/sasl/sysadmin.html The ldapdb auxprop plugin essentially requires that you have a clear text password stored within your ldap directory. It allows you to make use of a wider range of mechanisms, such as digest-md5. The ldapdb plugin is configured using the following options, in this case within your /etc/sasl2/smtpd.conf: ldapdb_uri ldapdb_id ldapdb_mech ldapdb_pw ldapdb_rc ldapdb_starttls auxprop_plugin canon_user_plugin See: https://www.sendmail.org/~ca/email/cyrus2/options.html If you don't intend to use the ldapdb plugin, you can shut the log messages up with: ldapdb_uri: ldapi:/// or auxprop_plugin: sasldb canon_user_plugin: sasldb The saslauthd daemon is a password verification daemon. It accepts authentication data from the user in clear text, and can authenticate the crendials using a wide range of methods (pam, ldap, etc). saslauthd only supports the plain and login authentication mechanisms. These two methods *can* be mixed - saslauthd for plain/login, and ldapdb for other mechanisms, to give you an idea of how they interoperate, but that makes no sense here. For documentation on the ldap saslauthd backend, see: https://github.com/cyrusimap/cyrus-sasl/blob/master/saslauthd/LDAP_SASLAUTHD The saslauthd ldap backend can work with a wider range of LDAP servers than the ldapdb plugin. >These are the files , and their locations I am trying to configure . ( am I missing any other files to configure ) > > > 1. /etc/saslauthd.conf > 2. /etc/sasl2/smtpd.conf This is a common location, but depending on your libsasl compile options, and your smtp server configuration, your server may look elsewhere. >My /etc/saslauthd.conf , is configured in the following way : > >ldap_servers: ldaps://< hostname >:636 >ldap_bind_dn: uid=xxx,ou=xx,ou=xx,o=xx >ldap_bind_pw: xxxx > >ldap_version: 3 >ldap_auth_method: bind >ldap_search_base: ou=xx,ou=ss,o=xx >ldap_scope: sub >ldap_filter: ShortName=%U > >*********************************************************************** > >The /etc/sasl2/smtpd.conf is configured as : > >pwcheck_method: auxprop >auxprop_plugin: ldapdb > >mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 > >**************************************************************** > >#ldapdb_mech: LOGIN ( I am not sure if this parameter should be configured under smtpd.conf or under saslauthd.conf ) This would go in your smtpd.conf, if you are using the ldapdb plugin. >Output of : saslauthd -a ldap -O /etc/saslauthd.conf > ># saslauthd -a ldap -O /etc/saslauthd.conf >saslauthd[91048] :detach_tty : Cannot start saslauthd >saslauthd[91048] :detach_tty : Another instance of saslauthd is currently running Presumably you are running postfix chrooted, and need to run a second instance of saslauthd with a mux located in a location that postfix can find. If that's the case, you'll need to specific a different location for the mux (-m) in a location postfix can access. If you don't need to be running two instances (the first is started by an init script?), then modify your saslauthd startup script to include your -O option, and the proper location for the mux. > * # ps aux | grep saslauthd > * root 84395 0.0 0.0 74456 956 ? Ss 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84396 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84397 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84398 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r > * root 84399 0.0 0.0 74456 732 ? S 18:25 0:00 /usr/sbin/saslauthd -m /run/saslauthd -a ldap -r At this point, if saslauthd is properly configured and your saslauthd.conf is correct, testsaslathd will succeed, and successfully authenticate against your ldap server. Also test it in a shell, as the postfix user, to verify all system persmissions are correct. You would want to have this working before you move on to your postfix and smtpd.conf configuration. >SASL related configuration under postfix / main.cf file . > >smtpd_sasl_auth_enable = yes >smtpd_sasl_type = cyrus > >smtpd_sasl_path = /run/saslauthd/mux >#smtpd_sasl_path = /usr/lib64/sasl2 This isn't correct. If I understand the config option, it should point to the location of your sasl smtpd.conf config file (/etc/sasl2). >smtpd_sasl_security_options = noanonymous >smtpd_tls_auth_only = yes >smtpd_sasl_tls_security_options = noanonymous On 04/27/20?20:22?+0000, Bandaru, Vamsi wrote: >Adding the output of pluginviewer : ldapdb is not listed as a one of the auxprop mechanisms : > ># /usr/sbin/pluginviewer -a > >Installed and properly configured auxprop mechanisms are: >sasldb >List of auxprop plugins follows >Plugin "sasldb" , API version: 8 > supports store: yes > >and I don't have a pluginviewer.conf on my system , another conf file I have is : /etc/sasl2/slapd.conf pluginviewer will fail, because it requires, at least, the ldapdb_uri option be configured. You would need to create a pluginviewer.conf, such as in /etc/sasl2, for this command to list ldapdb. ># cat /etc/sasl2/slapd.conf >mech_list: plain >pwcheck_method: saslauthd >saslauthd_path: /var/run/saslauthd/mux > > >( this doesn't look right ) This looks fine, unless you're running postfix smtpd chrooted, in which case you'll want to have the saslauthd mux located somewhere within the postfix chroot.