About a year-and-a-half ago I wrote in a thread having this same subject about a problem my sendmail server was having on my Samba4 AD/DC. To solve that problem at the time, I maintained domain user entries in both the sam.ldb and in /etc/passwd, and did not have winbind specified in /etc/nsswitch.conf. I am now trying to remove all users from /etc/passwd and use winbind. Unfortunately, I'm running into the same problem. In short: AD/DC:> getent passwd charmaineHPRS\charmaine:*:10003:10000:Charmaine Carter:/home/HPRS/charmaine:/bin/bash other domain member: $ getent passwd charmaine charmaine:*:10003:10000:Charmaine Carter:/home/HPRS/charmaine:/bin/bash The ID being return of "HPRS\charmaine" apparently confuses sendmail and procmail and causes the error, "Suspicious rcfile "/home/HPRS/charmaine/.procmailrc", probably due to "The owner of the rcfile was not the recipient or root" (from procmail manpage). Note that mail delivery worked OK when the user was in /etc/passwd. Currently, mail is not getting delivered the the Maildir as .procmailrc specifies, but rather it is sent to /var/spool/mail/HPRScharmaine, so it is obviously construction a mbox name based on the winbind returned ID. Regarding this issue, On Thu Jul 21 04:02 Rowland penny wrote:> There is another line, which works on a domain member: > > winbind use default domain = yes > > This (on a domain member) removes the NetBIOS domain name, but it > doesn't seem to work on an AD DC. >Various other participants on this thread confirmed that "winbind use default domain = yes" did not work on the AD/DC. Later (Mon Jul 25 12:05), Roland referenced a bug report on this issue: https://bugzilla.samba.org/show_bug.cgi?id=9780 Interestingly, on 2016-07-27 15:42:36 Björn Jacke posted to bugzilla that the issue was solved, and set the status to RESOLVED FIXED: "Samba 4.1 is old and out of support by us. Update to a recent version if you need this to be solved. Current Samba versions use a unified winbind with a more unified feature set." I am currently running version 4.4.16 and it is clearly not solved. Does anyone have a workaround for this? Later in that same thread (Thu Jul 21 12:30:40 2016) Mike E. suggested trying sssd, which was solving the problem for him. My distro (Slackware) does not have an sssd package, though I'll continue researching that. Otherwise, barring some other solution, I'll have to put my users back in /etc/passwd! Thanks for your help -- Mark
I've figured out a work-around to the problem of "winbind use default domain = yes" not working on the AD/DC. As mention below, in my specific case procmail does not see HPRS\charmaine as the actual owner 'charmaine' and I get a "Suspicious rcfile "/home/HPRS/charmaine/.procmailrc" message in maillog and the mail does not get delivered to her $HOME/Maildir file, but rather to /var/spool/mail/HPRScharmaine. Per the procmail man page, this error is because, "The owner of the rcfile was not the recipient or root, ... ". My work-around was to change the ownership of the .procmailrc file to root since that seemed acceptable to procmail. This worked and mail was then delivered. Comments: This "bug" has been hanging around in Samba since April, 2013, https://bugzilla.samba.org/show_bug.cgi?id=9780 It is currently marked as RESOLVED FIXED by Andrew Bartlett of as 2016-07-28, but it is clearly not solved. Anyone running `getent passwd` or `wbinfo` on the AD/DC will get "DOMAIN/user" instead of "user". Therefore, not solved. This functionality is inconsistent with the values returned by the same commands on a domain member. It currently breaks authentication for various facilities on the AD/DC, not limited to mail MTAs and MDAs. I've found a number of postings on this list about this problem. Some people, (Mike E. (posting Thu Jul 21 12:30:40 2016) have found other work-arounds including using sssd in nsswitch.conf instead of winbind. There are 10 postings on the bug report for people having the same problem including another (Luc Lalonde) who also switched to sssd. I believe this is a problem in the real-world and should be more urgently addressed by the Samba team. I think this is a fundamental piece of Samba4 and it should work correctly. My two cents worth. --Mark -----Original Message----- Date: Wed, 29 Nov 2017 10:48:06 -0500 To: samba at lists.samba.org User-Agent: Heirloom mailx 12.5 7/5/10 Subject: Re: [Samba] sendmail getting domain\user as email userId About a year-and-a-half ago I wrote in a thread having this same subject about a problem my sendmail server was having on my Samba4 AD/DC. To solve that problem at the time, I maintained domain user entries in both the sam.ldb and in /etc/passwd, and did not have winbind specified in /etc/nsswitch.conf. I am now trying to remove all users from /etc/passwd and use winbind. Unfortunately, I'm running into the same problem. In short: AD/DC:> getent passwd charmaineHPRS\charmaine:*:10003:10000:Charmaine Carter:/home/HPRS/charmaine:/bin/bash other domain member: $ getent passwd charmaine charmaine:*:10003:10000:Charmaine Carter:/home/HPRS/charmaine:/bin/bash The ID being return of "HPRS\charmaine" apparently confuses sendmail and procmail and causes the error, "Suspicious rcfile "/home/HPRS/charmaine/.procmailrc", probably due to "The owner of the rcfile was not the recipient or root" (from procmail manpage). Note that mail delivery worked OK when the user was in /etc/passwd. Currently, mail is not getting delivered the the Maildir as .procmailrc specifies, but rather it is sent to /var/spool/mail/HPRScharmaine, so it is obviously construction a mbox name based on the winbind returned ID. Regarding this issue, On Thu Jul 21 04:02 Rowland penny wrote:> There is another line, which works on a domain member: > > winbind use default domain = yes > > This (on a domain member) removes the NetBIOS domain name, but it > doesn't seem to work on an AD DC. >Various other participants on this thread confirmed that "winbind use default domain = yes" did not work on the AD/DC. Later (Mon Jul 25 12:05), Roland referenced a bug report on this issue: https://bugzilla.samba.org/show_bug.cgi?id=9780 Interestingly, on 2016-07-27 15:42:36 Björn Jacke posted to bugzilla that the issue was solved, and set the status to RESOLVED FIXED: "Samba 4.1 is old and out of support by us. Update to a recent version if you need this to be solved. Current Samba versions use a unified winbind with a more unified feature set." I am currently running version 4.4.16 and it is clearly not solved. Does anyone have a workaround for this? Later in that same thread (Thu Jul 21 12:30:40 2016) Mike E. suggested trying sssd, which was solving the problem for him. My distro (Slackware) does not have an sssd package, though I'll continue researching that. Otherwise, barring some other solution, I'll have to put my users back in /etc/passwd! Thanks for your help -- Mark -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
On Thu, 30 Nov 2017 11:34:54 -0500 Mark Foley via samba <samba at lists.samba.org> wrote:> I've figured out a work-around to the problem of "winbind use default > domain = yes" not working on the AD/DC. As mention below, in my > specific case procmail does not see HPRS\charmaine as the actual > owner 'charmaine' and I get a "Suspicious rcfile > "/home/HPRS/charmaine/.procmailrc" message in maillog and the mail > does not get delivered to her $HOME/Maildir file, but rather > to /var/spool/mail/HPRScharmaine. > > Per the procmail man page, this error is because, "The owner of the > rcfile was not the recipient or root, ... ". My work-around was to > change the ownership of the .procmailrc file to root since that > seemed acceptable to procmail. This worked and mail was then > delivered. > > Comments: > > This "bug" has been hanging around in Samba since April, 2013, > https://bugzilla.samba.org/show_bug.cgi?id=9780 It is currently > marked as RESOLVED FIXED by Andrew Bartlett of as 2016-07-28, but it > is clearly not solved. Anyone running `getent passwd` or `wbinfo` on > the AD/DC will get "DOMAIN/user" instead of "user". Therefore, not > solved. > > This functionality is inconsistent with the values returned by the > same commands on a domain member. > > It currently breaks authentication for various facilities on the > AD/DC, not limited to mail MTAs and MDAs. > > I've found a number of postings on this list about this problem. > Some people, (Mike E. (posting Thu Jul 21 12:30:40 2016) have found > other work-arounds including using sssd in nsswitch.conf instead of > winbind. There are 10 postings on the bug report for people having > the same problem including another (Luc Lalonde) who also switched to > sssd. > > I believe this is a problem in the real-world and should be more > urgently addressed by the Samba team. I think this is a fundamental > piece of Samba4 and it should work correctly. > > My two cents worth. > > --Mark > > -----Original Message----- > Date: Wed, 29 Nov 2017 10:48:06 -0500 > To: samba at lists.samba.org > User-Agent: Heirloom mailx 12.5 7/5/10 > Subject: Re: [Samba] sendmail getting domain\user as email userId > > About a year-and-a-half ago I wrote in a thread having this same > subject about a problem my sendmail server was having on my Samba4 > AD/DC. To solve that problem at the time, I maintained domain user > entries in both the sam.ldb and in /etc/passwd, and did not have > winbind specified in /etc/nsswitch.conf. I am now trying to remove > all users from /etc/passwd and use winbind. Unfortunately, I'm > running into the same problem. In short: > > AD/DC: > > getent passwd charmaine > HPRS\charmaine:*:10003:10000:Charmaine > Carter:/home/HPRS/charmaine:/bin/bash > > other domain member: > $ getent passwd charmaine > charmaine:*:10003:10000:Charmaine > Carter:/home/HPRS/charmaine:/bin/bash > > The ID being return of "HPRS\charmaine" apparently confuses sendmail > and procmail and causes the error, "Suspicious rcfile > "/home/HPRS/charmaine/.procmailrc", probably due to "The owner of the > rcfile was not the recipient or root" (from procmail manpage). Note > that mail delivery worked OK when the user was in /etc/passwd. > Currently, mail is not getting delivered the the Maildir > as .procmailrc specifies, but rather it is sent > to /var/spool/mail/HPRScharmaine, so it is obviously construction a > mbox name based on the winbind returned ID. > > Regarding this issue, On Thu Jul 21 04:02 Rowland penny wrote: > > > There is another line, which works on a domain member: > > > > winbind use default domain = yes > > > > This (on a domain member) removes the NetBIOS domain name, but it > > doesn't seem to work on an AD DC. > > > > Various other participants on this thread confirmed that "winbind use > default domain = yes" did not work on the AD/DC. Later (Mon Jul 25 > 12:05), Roland referenced a bug report on this issue: > > https://bugzilla.samba.org/show_bug.cgi?id=9780 > > Interestingly, on 2016-07-27 15:42:36 Björn Jacke posted to bugzilla > that the issue was solved, and set the status to RESOLVED FIXED: > > "Samba 4.1 is old and out of support by us. Update to a recent > version if you need this to be solved. Current Samba versions use a > unified winbind with a more unified feature set." > > I am currently running version 4.4.16 and it is clearly not solved. > > Does anyone have a workaround for this? Later in that same thread > (Thu Jul 21 12:30:40 2016) Mike E. suggested trying sssd, which was > solving the problem for him. My distro (Slackware) does not have an > sssd package, though I'll continue researching that. Otherwise, > barring some other solution, I'll have to put my users back > in /etc/passwd! > > Thanks for your help -- Mark >I have re-opened the bug report, the problem is that the devs don't see it as a problem, whilst a lot of users do :-( Rowland
Reasonably Related Threads
- sendmail getting domain\user as email userId
- sendmail getting domain\user as email userId
- sendmail getting domain\user as email userId
- sendmail getting domain\user as email userId [formerly: How to GSSAPI/Kerberos authenticate with Dovecot]
- sendmail getting domain\user as email userId [formerly: How to GSSAPI/Kerberos authenticate with Dovecot]