Web lists-archives.com

Re: [Samba] sendmail getting domain\user as email userId

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

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.


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

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.


-----Original Message-----
Date: Wed, 29 Nov 2017 10:48:06 -0500
To: samba@xxxxxxxxxxxxxxx
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:

> 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:


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

To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba