Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] How to GSSAPI/Kerberos authenticate with Dovecot [formerly Where is krb5.keytab or equivalent?]
794 views
Skip to first unread message
Mark Foley
Jul 3, 2016, 7:40:02 PM7/3/16
to
After a nearly 2-year struggle to get Dovecot to do either NTLM or GSSAPI authentication with
Samba4 AD/DC, I believe I've finally got it! Infinite thanks to Achim Gottinger for his
patience in working this through with me. Although my purpose was for Dovecot to authenticate
mail clients, the configuration settings needed were on the Samba side. I hope these
instructions can eventually make it into:
https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Configure_Kerberos
as those instruction contain nothing about the required `samba-tool spn add` and samba-tool domain
exportkeytab` settings, without which it is impossible to get Dovecot (and presumably other
local authenticators needing GSSAPI/Kerberos) to authenticate.
You need kerberos as the Samba built-in kerberos does not have needed commands like `klist`.
My distro (Slackware 14.1) does not come with kerberos, but is easily found at:
https://slackbuilds.org/repository/14.1/network/krb5/
Per the samba docs, copy the krb5.conf template created when provisioned:
$ cp /usr/local/samba/private/krb5.conf /etc/krb5.conf
(Note: the actual docs advise symlinking:
ln -sf /usr/local/samba/private/krb5.conf /etc/krb5.conf
but I prefer making a copy in case I need to modify things).
I've set The /etc/krb5.conf file to world readable. It's default contents are (and these do
not need to be changed):
[libdefaults]
default_realm = HPRS.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = true
where HPRS.LOCAL is my realm, of course use your own.
Now, we need a samba user in order to create the necessary SPNs (Server Principal Names):
$ samba-tool user create dovecot
New Password:
Retype Password:
User 'dovecot' created successfully
Next, add the SPN(s), and create the keytab:
$ samba-tool spn add imap/mail.hprs.local dovecot
$ samba-tool domain exportkeytab --principal imap/mail.hprs.local dovecot.keytab
Dovecot does not do my (outgoing) SMTP serving, only (incoming) IMAP, but if it did I'd have to
create another SPN for smtp:
$ samba-tool spn add smtp/mail.hprs.local dovecot
$ samba-tool domain exportkeytab --principal smtp/mail.hprs.local dovecot.keytab
Dovecot needs to be able to read the keytab file:
$ chgrp dovecot /etc/dovecot/dovecot.keytab
$ chmod g+r /etc/dovecot/dovecot.keytab
my new keytab:
$ klist -Kek /etc/dovecot/dovecot.keytab
Keytab name: FILE:/etc/dovecot/dovecot.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 imap/mail.hp...@HPRS.LOCAL (des-cbc-crc) (0x232616c2a4fd08f7)
1 imap/mail.hp...@HPRS.LOCAL (des-cbc-md5) (0x232616c2a4fd08f7)
1 imap/mail.hp...@HPRS.LOCAL (arcfour-hmac) (0x9dae89a221dc374a39f560833352f60f)
(and if I also created the spn for smtp I would also have these:)
1 smtp/mail.hp...@HPRS.LOCAL (des-cbc-crc) (0x232616c2a4fd08f7)
1 smtp/mail.hp...@HPRS.LOCAL (des-cbc-md5) (0x232616c2a4fd08f7)
1 smtp/mail.hp...@HPRS.LOCAL (arcfour-hmac) (0x9dae89a221dc374a39f560833352f60f)
DOVECOT SETTINGS:
Of crucial importance is to buld dovecot with GSSAPI! That is NOT one of the default settings.
In the build directory:
./configure --with-gssapi=yes
Otherwise, settings are pretty simple. Add the following 3 settings to 10-auth.conf:
auth_gssapi_hostname = "$ALL"
auth_krb5_keytab = /etc/dovecot/dovecot.keytab
auth_mechanisms = plain login gssapi
The auth_gssapi_hostname is supposedly not required according to dovecotList comments, but my
10-auth.conf template implies differently, so it can't hurt.
I couldn't get any of this working until I rebooted the Samba AD/DC-Dovecot server, but that
just may have been me not stopping/starting Samba and Dovecot in the right sequence (or, I
needed a Samba upgrade to 4.2!).
In my WIN7 and Ubuntu Thunderbird clients I selected gssapi/kerberos for the IMAP authenticate
method and it works!
Again, thanks to Achim for his critical help.
Someone please put at least the required samba-tool commands into the wiki for other poor
schmucks like me.
--Mark
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Samba4 AD/DC, I believe I've finally got it! Infinite thanks to Achim Gottinger for his
patience in working this through with me. Although my purpose was for Dovecot to authenticate
mail clients, the configuration settings needed were on the Samba side. I hope these
instructions can eventually make it into:
https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Configure_Kerberos
as those instruction contain nothing about the required `samba-tool spn add` and samba-tool domain
exportkeytab` settings, without which it is impossible to get Dovecot (and presumably other
local authenticators needing GSSAPI/Kerberos) to authenticate.
You need kerberos as the Samba built-in kerberos does not have needed commands like `klist`.
My distro (Slackware 14.1) does not come with kerberos, but is easily found at:
https://slackbuilds.org/repository/14.1/network/krb5/
Per the samba docs, copy the krb5.conf template created when provisioned:
$ cp /usr/local/samba/private/krb5.conf /etc/krb5.conf
(Note: the actual docs advise symlinking:
ln -sf /usr/local/samba/private/krb5.conf /etc/krb5.conf
but I prefer making a copy in case I need to modify things).
I've set The /etc/krb5.conf file to world readable. It's default contents are (and these do
not need to be changed):
[libdefaults]
default_realm = HPRS.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = true
where HPRS.LOCAL is my realm, of course use your own.
Now, we need a samba user in order to create the necessary SPNs (Server Principal Names):
$ samba-tool user create dovecot
New Password:
Retype Password:
User 'dovecot' created successfully
Next, add the SPN(s), and create the keytab:
$ samba-tool spn add imap/mail.hprs.local dovecot
$ samba-tool domain exportkeytab --principal imap/mail.hprs.local dovecot.keytab
Dovecot does not do my (outgoing) SMTP serving, only (incoming) IMAP, but if it did I'd have to
create another SPN for smtp:
$ samba-tool spn add smtp/mail.hprs.local dovecot
$ samba-tool domain exportkeytab --principal smtp/mail.hprs.local dovecot.keytab
Dovecot needs to be able to read the keytab file:
$ chgrp dovecot /etc/dovecot/dovecot.keytab
$ chmod g+r /etc/dovecot/dovecot.keytab
my new keytab:
$ klist -Kek /etc/dovecot/dovecot.keytab
Keytab name: FILE:/etc/dovecot/dovecot.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 imap/mail.hp...@HPRS.LOCAL (des-cbc-crc) (0x232616c2a4fd08f7)
1 imap/mail.hp...@HPRS.LOCAL (des-cbc-md5) (0x232616c2a4fd08f7)
1 imap/mail.hp...@HPRS.LOCAL (arcfour-hmac) (0x9dae89a221dc374a39f560833352f60f)
(and if I also created the spn for smtp I would also have these:)
1 smtp/mail.hp...@HPRS.LOCAL (des-cbc-crc) (0x232616c2a4fd08f7)
1 smtp/mail.hp...@HPRS.LOCAL (des-cbc-md5) (0x232616c2a4fd08f7)
1 smtp/mail.hp...@HPRS.LOCAL (arcfour-hmac) (0x9dae89a221dc374a39f560833352f60f)
DOVECOT SETTINGS:
Of crucial importance is to buld dovecot with GSSAPI! That is NOT one of the default settings.
In the build directory:
./configure --with-gssapi=yes
Otherwise, settings are pretty simple. Add the following 3 settings to 10-auth.conf:
auth_gssapi_hostname = "$ALL"
auth_krb5_keytab = /etc/dovecot/dovecot.keytab
auth_mechanisms = plain login gssapi
The auth_gssapi_hostname is supposedly not required according to dovecotList comments, but my
10-auth.conf template implies differently, so it can't hurt.
I couldn't get any of this working until I rebooted the Samba AD/DC-Dovecot server, but that
just may have been me not stopping/starting Samba and Dovecot in the right sequence (or, I
needed a Samba upgrade to 4.2!).
In my WIN7 and Ubuntu Thunderbird clients I selected gssapi/kerberos for the IMAP authenticate
method and it works!
Again, thanks to Achim for his critical help.
Someone please put at least the required samba-tool commands into the wiki for other poor
schmucks like me.
--Mark
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Rowland penny
Jul 4, 2016, 3:30:03 AM7/4/16
to
On 04/07/16 00:34, Mark Foley wrote:
> After a nearly 2-year struggle to get Dovecot to do either NTLM or GSSAPI authentication with
> Samba4 AD/DC, I believe I've finally got it! Infinite thanks to Achim Gottinger for his
> patience in working this through with me. Although my purpose was for Dovecot to authenticate
> mail clients, the configuration settings needed were on the Samba side. I hope these
> instructions can eventually make it into:
>
> https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Configure_Kerberos
>
> as those instruction contain nothing about the required `samba-tool spn add` and samba-tool domain
> exportkeytab` settings, without which it is impossible to get Dovecot (and presumably other
> local authenticators needing GSSAPI/Kerberos) to authenticate.
The problem is that Samba doesn't recommend using the DC as a fileserver
> After a nearly 2-year struggle to get Dovecot to do either NTLM or GSSAPI authentication with
> Samba4 AD/DC, I believe I've finally got it! Infinite thanks to Achim Gottinger for his
> patience in working this through with me. Although my purpose was for Dovecot to authenticate
> mail clients, the configuration settings needed were on the Samba side. I hope these
> instructions can eventually make it into:
>
> https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Configure_Kerberos
>
> as those instruction contain nothing about the required `samba-tool spn add` and samba-tool domain
> exportkeytab` settings, without which it is impossible to get Dovecot (and presumably other
> local authenticators needing GSSAPI/Kerberos) to authenticate.
etc This is why it isn't mentioned, on a correctly set up domain member,
the keytab is created during the join.
>
> You need kerberos as the Samba built-in kerberos does not have needed commands like `klist`.
kerberos tools.
not a DC.
Rowland
Achim Gottinger
Jul 4, 2016, 3:40:03 AM7/4/16
to
'auth_gssapi_hostname = "$ALL"'? In my tests with those principals it
worked without it.
With Samba 4.4.3 there are also aes 128/256 versions of the keys in the
exported keytab.
On Windows 7 kinit shows what encryption was used. With arcfour-hmac it
shows rc4-hmac.
achim~
Mark Foley
Jul 4, 2016, 4:20:03 PM7/4/16
to
On Mon, 4 Jul 2016 08:18:11 +0100 Rowland penny <rpe...@samba.org> wrote:
> The problem is that Samba doesn't recommend using the DC as a fileserver
> etc This is why it isn't mentioned,
Well, I don't see that the DC is being used as an actual file server simply by hosting an email
> The problem is that Samba doesn't recommend using the DC as a fileserver
> etc This is why it isn't mentioned,
server. There is no share defined in smb.conf to accomodate this. Furthermore, I think it is
common practice for the AD/DC to also be the mail server. Certainly that has been my
experience, esp. coming from the Microsoft universe with the typical small business
configuration of SBS and Exchange on the same host; now replaced by Samba4 and Dovecot/IMAP.
Since Dovecot is only trying to authenticate, I don't see how this could possibly be a NOT
RECOMMENDED configuration.
> on a correctly set up domain member, the keytab is created during the join.
kerberos authentication to domain members.
> > Someone please put at least the required samba-tool commands into the wiki for other poor
> > schmucks like me.
> >
> > --Mark
> Will do, but it will be phrased in the context of using a domain member
> not a DC.
for single-sign-on about a year ago and that required nothing special on the AD/DC. I think
Samba/Kerberos works for domain members, but not for authentication on the same host running
the DC. I think it's fallacious to assume the mail server will be on a standalone host/domain
member. Maybe in the Microsoft world, but Linux certainly has the horsepower to handle AD/DC
and Mailserver on the same box.
--Mark
Mark Foley
Jul 4, 2016, 4:30:03 PM7/4/16
to
> To: sa...@lists.samba.org
> From: Achim Gottinger <ac...@ag-web.biz>
> Date: Mon, 4 Jul 2016 09:29:02 +0200
Thanks Achim, no haven't tried without the auth_gssapi_hostname settings, though it probably
will work. The dovecot people seemed to think so. I'm giving this a rest to let my brain cool
down. Perhaps I'll try it later.
Please weight in on Rowland's comment about restricting documentation on kerberos
authentication to domain members. I've posted a dissenting view, but maybe I'm alone in my
opinion that there should be no issue running a mail server on the same box as the AD/DC.
Perhaps few people do that, but my feeling is that most people do that. Feedback by you and
others as to real-world use could be valuable.
--Mark
> From: Achim Gottinger <ac...@ag-web.biz>
> Date: Mon, 4 Jul 2016 09:29:02 +0200
> Subject: Re: [Samba] How to GSSAPI/Kerberos authenticate with Dovecot
>
>
will work. The dovecot people seemed to think so. I'm giving this a rest to let my brain cool
down. Perhaps I'll try it later.
Please weight in on Rowland's comment about restricting documentation on kerberos
authentication to domain members. I've posted a dissenting view, but maybe I'm alone in my
opinion that there should be no issue running a mail server on the same box as the AD/DC.
Perhaps few people do that, but my feeling is that most people do that. Feedback by you and
others as to real-world use could be valuable.
--Mark
Rowland penny
Jul 4, 2016, 4:40:03 PM7/4/16
to
On 04/07/16 21:15, Mark Foley wrote:
> On Mon, 4 Jul 2016 08:18:11 +0100 Rowland penny <rpe...@samba.org> wrote:
>
>> The problem is that Samba doesn't recommend using the DC as a fileserver
>> etc This is why it isn't mentioned,
> Well, I don't see that the DC is being used as an actual file server simply by hosting an email
> server. There is no share defined in smb.conf to accomodate this. Furthermore, I think it is
> common practice for the AD/DC to also be the mail server. Certainly that has been my
> experience, esp. coming from the Microsoft universe with the typical small business
> configuration of SBS and Exchange on the same host; now replaced by Samba4 and Dovecot/IMAP.
> Since Dovecot is only trying to authenticate, I don't see how this could possibly be a NOT
> RECOMMENDED configuration.
Samba only recommends using the DC for authentication, now I live in the
> On Mon, 4 Jul 2016 08:18:11 +0100 Rowland penny <rpe...@samba.org> wrote:
>
>> The problem is that Samba doesn't recommend using the DC as a fileserver
>> etc This is why it isn't mentioned,
> Well, I don't see that the DC is being used as an actual file server simply by hosting an email
> server. There is no share defined in smb.conf to accomodate this. Furthermore, I think it is
> common practice for the AD/DC to also be the mail server. Certainly that has been my
> experience, esp. coming from the Microsoft universe with the typical small business
> configuration of SBS and Exchange on the same host; now replaced by Samba4 and Dovecot/IMAP.
> Since Dovecot is only trying to authenticate, I don't see how this could possibly be a NOT
> RECOMMENDED configuration.
real world and know that people will use it for other purposes. The wiki
used to be littered with how to this , that and the other on the DC,
there were other pages that had similar info for domain members and
quite frankly, it was a mess. Marc Muhelfeld sorted out the wiki, basing
it around Samba's recommendations, I am not going to start undoing all
Marc's hard work.
>> on a correctly set up domain member, the keytab is created during the join.
> Probably true for a domain member, but not for the AD/DC. I disagree that you should restrict
> kerberos authentication to domain members.
said that when you join a domain member, you get a keytab.
>
>>> Someone please put at least the required samba-tool commands into the wiki for other poor
>>> schmucks like me.
>>>
>>> --Mark
>> Will do, but it will be phrased in the context of using a domain member
>> not a DC.
> Your the boss, but I don't think that covers the issue. You helped me set up a domain member
> for single-sign-on about a year ago and that required nothing special on the AD/DC. I think
> Samba/Kerberos works for domain members, but not for authentication on the same host running
> the DC. I think it's fallacious to assume the mail server will be on a standalone host/domain
> member. Maybe in the Microsoft world, but Linux certainly has the horsepower to handle AD/DC
> and Mailserver on the same box.
>
> --Mark
>
>
your DC and you can do whatever you like with it.
Rowland penny
Jul 4, 2016, 4:50:03 PM7/4/16
to
I have no real problem with putting the info on the Samba wiki, but as I
said, stuff like this used to be on the wiki and it was removed during
Marc's clean up.
If Marc gives the go ahead, I will add it, if he says no, then I won't,
there is no point in adding something that Marc is just going to remove.
Rowland
Achim Gottinger
Jul 4, 2016, 5:10:03 PM7/4/16
to
The samba wiki contains an article for OpenSSH Single Sign on.
https://wiki.samba.org/index.php/OpenSSH_Single_sign-on.
It is not required for dovecot run run on the samba server. It can be an
different server, the service principals for imap/pop/smtp must be
created on the samba domain. The keytab file must be copied to the
dovecot server.
An howto about creating and exporting special service principals would
be helpfull for kerberized nfs as well. In this case the nfs server can
also be an seperate machine.
achim~
Jules Houantonon
Jul 4, 2016, 5:20:02 PM7/4/16
to
Thank you for sharing this Informations.
Good job !
Good job !
Mark Foley
Jul 14, 2016, 11:00:03 AM7/14/16
to
> Date: Mon, 4 Jul 2016 21:43:46 +0100
Yes, they did add it to the dovecot wiki: http://wiki2.dovecot.org/Authentication/Kerberos
Certainly, check with Marc. I wouldn't advocate doing things against policy (but changing the
policy a bit?) Even though this is about dovecot specifically, in general, one should be able
to authenticate locally, as you mention in your email of July 4, 21:30:
"Samba only recommends using the DC for authentication, ... I never said that [kerberos
authentication is restricted to domain members], you can have kerberos authentication on a DC,"
The instructions on letting dovecot authenticate on the DC is a paradigm example. Users could
easily extrapolate that to other tools that need to authenticate. Perhaps the instructions
could be generalized and leaving of the dovecot config stuff, and changing the domain user and
keytab name to something not specifically saying "dovecot".
Thanks for all you help!
--Mark
> Subject: Re: [Samba] How to GSSAPI/Kerberos authenticate with Dovecot
> [formerly Where is krb5.keytab or equivalent?]
Certainly, check with Marc. I wouldn't advocate doing things against policy (but changing the
policy a bit?) Even though this is about dovecot specifically, in general, one should be able
to authenticate locally, as you mention in your email of July 4, 21:30:
"Samba only recommends using the DC for authentication, ... I never said that [kerberos
authentication is restricted to domain members], you can have kerberos authentication on a DC,"
The instructions on letting dovecot authenticate on the DC is a paradigm example. Users could
easily extrapolate that to other tools that need to authenticate. Perhaps the instructions
could be generalized and leaving of the dovecot config stuff, and changing the domain user and
keytab name to something not specifically saying "dovecot".
Thanks for all you help!
--Mark
Rowland penny
Jul 14, 2016, 11:30:03 AM7/14/16
to
On 14/07/16 15:53, Mark Foley wrote:
> Yes, they did add it to the dovecot wiki: http://wiki2.dovecot.org/Authentication/Kerberos
>
> Certainly, check with Marc. I wouldn't advocate doing things against policy (but changing the
> policy a bit?) Even though this is about dovecot specifically, in general, one should be able
> to authenticate locally, as you mention in your email of July 4, 21:30:
>
> "Samba only recommends using the DC for authentication, ... I never said that [kerberos
> authentication is restricted to domain members], you can have kerberos authentication on a DC,"
>
> The instructions on letting dovecot authenticate on the DC is a paradigm example. Users could
> easily extrapolate that to other tools that need to authenticate. Perhaps the instructions
> could be generalized and leaving of the dovecot config stuff, and changing the domain user and
> keytab name to something not specifically saying "dovecot".
>
> Thanks for all you help!
>
> --Mark
>
I don't think the problem is with mentioning 'Dovecot', it is with using
> Yes, they did add it to the dovecot wiki: http://wiki2.dovecot.org/Authentication/Kerberos
>
> Certainly, check with Marc. I wouldn't advocate doing things against policy (but changing the
> policy a bit?) Even though this is about dovecot specifically, in general, one should be able
> to authenticate locally, as you mention in your email of July 4, 21:30:
>
> "Samba only recommends using the DC for authentication, ... I never said that [kerberos
> authentication is restricted to domain members], you can have kerberos authentication on a DC,"
>
> The instructions on letting dovecot authenticate on the DC is a paradigm example. Users could
> easily extrapolate that to other tools that need to authenticate. Perhaps the instructions
> could be generalized and leaving of the dovecot config stuff, and changing the domain user and
> keytab name to something not specifically saying "dovecot".
>
> Thanks for all you help!
>
> --Mark
>
the DC for anything other than authentication.
Reading the Dovecot wiki page, creating the user & SPN on the DC is
okay, but once you start exporting the keytab to be used on the DC, you
are doing something that Samba doesn't recommend, but I have thought of
a way around this, phrase the page in the same way as the Apache page on
the wiki.
By the way, did you know that 'samba-tool user create' has a switch to
create a random password for you: '--random-password'
Rowland
Rowland
Andrew Bartlett
Jul 14, 2016, 5:00:03 PM7/14/16
to
In particular, I can confirm this is the recomended approach for additional services, be they on the DC or (more usually) another server.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Andrew Bartlett
Jul 14, 2016, 5:00:03 PM7/14/16
to
On Thu, 2016-07-14 at 16:20 +0100, Rowland penny wrote:
> I don't think the problem is with mentioning 'Dovecot', it is with
> using
> the DC for anything other than authentication.
>
> Reading the Dovecot wiki page, creating the user & SPN on the DC is
> okay, but once you start exporting the keytab to be used on the DC,
> you
> are doing something that Samba doesn't recommend, but I have thought
> of
> a way around this, phrase the page in the same way as the Apache page
> on
> the wiki.
Rowland:
> I don't think the problem is with mentioning 'Dovecot', it is with
> using
> the DC for anything other than authentication.
>
> Reading the Dovecot wiki page, creating the user & SPN on the DC is
> okay, but once you start exporting the keytab to be used on the DC,
> you
> are doing something that Samba doesn't recommend, but I have thought
> of
> a way around this, phrase the page in the same way as the Apache page
> on
> the wiki.
Running samba-tool domain exportkeytab for a specific user is quite a
reasonable thing to do, and is entirely sensible to recommand as part
of adding a new user with an SPN. They keytab can then be deployed as
required.
Running the exportkeytab file is not the same as loading up the DC with
other services. Not that this is a total disaster (particularly for
small sites trying to replace SBS), but we do try and make folks think
before creating mega-servers.
I'm very happy for such information to be in our wiki, as I do refer to
it and refer others to the apache page, which shows the same pattern as
required for mod_auth_kerb.
https://wiki.samba.org/index.php/Authenticating_Apache_against_Active_D
irectory
Indeed, we need to make this page easier to find.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Rowland penny
Jul 14, 2016, 5:10:03 PM7/14/16
to
Dovecot on the DC. Now, if you are happy to say that Samba is now
recommending using the Samba AD DC as a fileserver etc, I am quite happy
to trawl the wiki, removing any references to not using the DC as a
fileserver etc, otherwise, I will go back to my plan of creating a wiki
page for Dovecot similar to the Apache one.
Rowland
Mark Foley
Jul 14, 2016, 5:30:03 PM7/14/16
to
On Thu, 14 Jul 2016 16:20:22 +0100 Rowland penny <rpe...@samba.org> wrote:
> By the way, did you know that 'samba-tool user create' has a switch to
> create a random password for you: '--random-password'
>
> Rowland
Didn't even think of that. I guess if there's never a need to log in as that user (e.g.
> By the way, did you know that 'samba-tool user create' has a switch to
> create a random password for you: '--random-password'
>
> Rowland
creating the user for SPN), that's a great idea.
--Mark
Andrew Bartlett
Jul 14, 2016, 7:40:02 PM7/14/16
to
on a DC, and in any case, we can afford to be a little less dogmatic
about this. Â Please don't go trawling the wiki one way or the other.Â
To be clear: I'm happy with the statement currently on the wiki:
Whilst the Domain Controller seems capable of running as a full file
server, it is suggested that organisations run a distinct file server
to allow upgrades of each without disrupting the other. It is also
suggested that medium-sized sites should run more than one DC. It also
makes sense to have the DC's distinct from any file servers that may
use the Domain Controllers. Additionally using distinct file servers
avoids the idiosyncrasies in the winbindd configuration on the Active
Directory Domain Controller. The Samba team does not recommend using a
Samba-based Domain Controller as a file server, and recommend that
users run a separate Domain Member with file shares.Â
Thanks,
Andrew Bartlett
--
Andrew Bartlett
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
https://catalyst.net.nz/services/samba
Rowland penny
Jul 15, 2016, 3:30:03 AM7/15/16
to
Dovecot on my TODO list, it will be based around the Apache page i.e. it
will say what user & SPN to create and then say howto transfer the
resultant keytab to another machine, leaving it up to the sysadmin to
read between the lines.
This is what I planned to do.
Rowland
Rowland penny
Jul 16, 2016, 3:40:03 AM7/16/16
to
it and realised there is a potential problem.
The user created in AD is called 'dovecot' and the Dovecot packages also
want to create a user called 'dovecot' in /etc/passwd, they cannot both
exist.
Not have having posting rights on the Dovecot list (and I don't want to
sign up to ask one question), I have asked Marc to ask Dovecot if we can
use a different name in AD.
Achim Gottinger
Jul 16, 2016, 9:10:03 AM7/16/16
to
That was my mistak, of course you can use any username you want on the
samba side. only the spn names are essential.
achim~
Mark Foley
Jul 16, 2016, 2:20:03 PM7/16/16
to
and procmail as MTA to deliver mail to the appropriate Maildir folders (as defined in
/etc/passwd for home directories) and I use /etc/shadow as Dovecot's passdb for non-domain mail
clients such as iPhone and Outlook (the latter simply because I haven't figured out NTML
authentication for Outlook yet).
All domain members, Windows or Linux, authenticate users with their AD credentials just fine.
What I did do with AD users and did not do with the AD dovecot user is create their /etc/passwd
entry with the same UID:GID as the AD account. So, for the dovecot user I could have:
samba-tool user add dovecot --random-password --uid-number=151 --gid-number=151
I did not do that for the AD dovecot user, but it doesn't seem to have mattered. I suppose,
given than you can use --random-password, no dovecot or AD components need to "log in" as the
dovecot user. The dovecot user is in the AD only to facilitate creation of the SPNs.
Whether or not this is recomended, I have been running with this setup flawlessly now for
nearly 2 years. ... nor do I recall specifically reading anywhere that AD users CAN NOT be in
/etc/passwd -- back when I was first setting up the AD/DC that would have given me pause.
--Mark
Rowland penny
Jul 16, 2016, 2:50:07 PM7/16/16
to
and have you tried creating a new local Unix user lately if that user
exists in AD already ?
User 'rowland' is in AD:
root@devstation:/home/rowland/dovecot# getent passwd rowland
rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
If the 'root' user tries to create a local Unix user called 'rowland'
root@devstation:/home/rowland/dovecot# useradd rowland
useradd: user 'rowland' already exists
Still think it is a good idea having your users in /etc/passwd & AD ?
You don't need to anyway, Dovecot can use the mail or userPrincipalName
attributes.
Rowland
>
> All domain members, Windows or Linux, authenticate users with their AD credentials just fine.
>
> What I did do with AD users and did not do with the AD dovecot user is create their /etc/passwd
> entry with the same UID:GID as the AD account. So, for the dovecot user I could have:
'uidNumber' attribute.
Achim Gottinger
Jul 16, 2016, 3:40:03 PM7/16/16
to
Using dovecot fpr the samba user does not hurt.
The samba dovecot uid is at no place required for kerberos authetification.
Mark Foley
Jul 17, 2016, 2:20:03 AM7/17/16
to
On Sat, 16 Jul 2016 19:39:21 +0100 Rowland penny <rpe...@samba.org> wrote:
>
> On 16/07/16 19:09, Mark Foley wrote:
> > On Sat, 16 Jul 2016 08:28:14 +0100 Rowland penny <rpe...@samba.org> wrote:
> >
[lots of extraneous stuff deleted]
>
> On 16/07/16 19:09, Mark Foley wrote:
> > On Sat, 16 Jul 2016 08:28:14 +0100 Rowland penny <rpe...@samba.org> wrote:
> >
> >>>
> >>>
> >> OK, just an update on the new wiki page for Dovecot, I started to write
> >> it and realised there is a potential problem.
> >>
> >> The user created in AD is called 'dovecot' and the Dovecot packages also
> >> want to create a user called 'dovecot' in /etc/passwd, they cannot both
> >> exist.
> >
> > Actually, yes they can. *ALL* my domain users are also in /etc/passwd because I use sendmail
> > and procmail as MTA to deliver mail to the appropriate Maildir folders (as defined in
> > /etc/passwd for home directories) and I use /etc/shadow as Dovecot's passdb for non-domain mail
> > clients such as iPhone and Outlook (the latter simply because I haven't figured out NTML
> > authentication for Outlook yet).
>
> Then, when you run 'getent passwd userA' which user do you get back ?
> and have you tried creating a new local Unix user lately if that user
> exists in AD already ?
>
> User 'rowland' is in AD:
>
> root@devstation:/home/rowland/dovecot# getent passwd rowland
> rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
>
> If the 'root' user tries to create a local Unix user called 'rowland'
>
> root@devstation:/home/rowland/dovecot# useradd rowland
> useradd: user 'rowland' already exists
On the AD/DC I then ran wbinfo to verify the uid/gid:
root@mail:~ # wbinfo -i shay
HPRS\shay:*:10010:10000:Susan Hay:/home/HPRS/shay:/bin/false
Then I added that user to the AD/DC /etc/passwd for reasons mentioned above. Here is the
actual command line still in root's bash command history:
useradd -c "Susan Hay" -d /home/HPRS/shay -g 10000 -m -s /bin/bash -u 10010 shay
I did not get the "useradd: user 'shay' already exists" message you got.
My getent:
root@mail:~ # getent passwd shay
shay:x:10010:10000:Susan Hay:/home/HPRS/shay:/bin/bash
Running getent on this user from a domain member (where that user IS NOT in any local passwd file):
mfoley@labrat:~ $ getent passwd shay
shay:*:10010:10000:Susan Hay:/home/shay:/bin/sh
> Still think it is a good idea having your users in /etc/passwd & AD ?
>
> You don't need to anyway, Dovecot can use the mail or userPrincipalName
> attributes.
incoming mail to /home/HPRS/username/Maildir. To my knowledge, sendmail cannot otherwise
determine user or destination mail directories. Perhaps other MTAs can get this info from
Samba4, but I don't think sendmail can.
> >
> > All domain members, Windows or Linux, authenticate users with their AD credentials just fine.
> >
> > What I did do with AD users and did not do with the AD dovecot user is create their /etc/passwd
> > entry with the same UID:GID as the AD account. So, for the dovecot user I could have:
>
> You do need the local Unix users in AD then, just give them a
> 'uidNumber' attribute.
--Mark
Mark Foley
Jul 17, 2016, 2:30:03 AM7/17/16
to
Linux on the AD/DC Dovecot host in January, 2015. The as-shipped must be fine. Mine is:
passwd: compat
group: compat
hosts: files dns
networks: files
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
No winbind on the AD/DC, but windbind is in the domain members' nsswitch.conf:
passwd: compat winbind
group: compat winbind
--Mark
Rowland penny
Jul 17, 2016, 3:40:02 AM7/17/16
to
What I am trying to tell you is that you shouldn't have users in AD and
/etc/passwd, in fact there is no need to.
The whole point of AD is centralisation of user and group management,
you can take your AD user and make it a Unix user by adding RFC2307
attributes to the users object in AD.
See here for the RFC: https://www.ietf.org/rfc/rfc2307.txt
In your setup you could have a user 'USERA' in AD and on your mail
computer you could also have a 'USERA' in /etc/passwd, how do you keep
the password for the two users in sync ? what happens if the AD user
changes their password ?
My systems are setup correctly and I cannot create a local Unix user if
the user exists in AD, but this doesn't matter, because I do not need
to. If I want an AD user to also be a Unix user, I just add the required
RFC2307 attributes to the users object in AD.
If I run this command on a Unix domain member:
rowland@devstation:~$ cat /etc/passwd | grep rowland
rowland@devstation:~$
I get nothing returned, so the user 'rowland' doesn't exist in
/etc/passwd, but if I then run this command:
rowland@devstation:~$ getent passwd rowland
rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
Funny, I seem to have a Unix user called 'rowland', but he doesn't exist
in /etc/passwd and if I wanted to use this user with Dovecot, I could.
Rowland
Data Control Systems - Mike Elkevizth
Jul 17, 2016, 9:40:11 AM7/17/16
to
Hi Mark,
I think the reason you did not get the 'user already exists' message when
doing a useradd is because your nsswitch file doesn't include winbind on
the server you ran it on. My system will give me the same warning as
Rowland's gives him with nsswitch setup like this:
passwd: compat winbind
group: compat winbind
My guess is that you had to add the users into /etc/passwd because of your
nsswitch file not using winbind. Otherwise your MTA should work fine.
Mine does.
I do also have these lines in my smb.conf, but I'm not sure they are
necessary for the MTA to work.
winbind enum groups = yes
winbind enum users = yes
Mike E.
I think the reason you did not get the 'user already exists' message when
doing a useradd is because your nsswitch file doesn't include winbind on
the server you ran it on. My system will give me the same warning as
Rowland's gives him with nsswitch setup like this:
passwd: compat winbind
group: compat winbind
nsswitch file not using winbind. Otherwise your MTA should work fine.
Mine does.
I do also have these lines in my smb.conf, but I'm not sure they are
necessary for the MTA to work.
winbind enum groups = yes
winbind enum users = yes
Mike E.
Achim Gottinger
Jul 17, 2016, 1:00:03 PM7/17/16
to
works fine with dovecot for kerberos authentification since two years.
So just use something like dovecot-krb and not dovecot as i recommended
mark in one of my eralier mails in this thread. It i sless confusing
that way.
Mark Foley
Jul 20, 2016, 1:10:03 PM7/20/16
to
/etc/passwd, that would be great. I'll post back results.
> In your setup you could have a user 'USERA' in AD and on your mail
> computer you could also have a 'USERA' in /etc/passwd,
> how do you keep the password for the two users in sync ? what happens if the AD
> user changes their password ?
authentication. Users never log onto the AD/DC directly, certainly not at the command line.
User logging into domain members, Linux or Windows, command line or not, use their AD
credentials. Their /etc/passwd password on the DC in never involved.
The DC's /etc/password entries are used solely for Sendmail/procmail to deliver mail to the
user's target email folders.
It's kind of analogous to `samba-tool user create dovecot --ramdom-password`. The idea is
simply to create an entry.
Having said that, if the user would need to sync or change their /etc/passwd password I have
provided an application for them to do that which uses chpasswd on the AD/DC. This also
updates the Apache passwords (if any). This mechanism has not been needed in the 2 years since
I created it.
> My systems are setup correctly and I cannot create a local Unix user if
Well, perhaps a later version of Samba adds this check (I have 4.2.12). I really did nothing
special to my samba set up. I followed the wiki for the smb.conf exactly. Samba itself came
with my distro, no building needed on my part.
> but this doesn't matter, because I do not need to. If I want an AD user to also be a Unix
> user, I just add the required RFC2307 attributes to the users object in AD.
>
> If I run this command on a Unix domain member:
>
> rowland@devstation:~$ cat /etc/passwd | grep rowland
> rowland@devstation:~$
>
> I get nothing returned, so the user 'rowland' doesn't exist in
> /etc/passwd, but if I then run this command:
>
> rowland@devstation:~$ getent passwd rowland
> rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
>
> Funny, I seem to have a Unix user called 'rowland', but he doesn't exist
> in /etc/passwd and if I wanted to use this user with Dovecot, I could.
>
> Rowland
(it did use it before with the PLAIN auth method). As I said, that entry is there soley for
Sendmail/procmail to locate the user's target email folders. If sendmail could AD authenticate
I wouldn't need /etc/passwd at all.
I'll definately check out that RFC2307 to see if that would takes care of the sendmail issue
and I'll post back my findings.
And before anyone asks ... no, we're not likely to get rid of sendmail any time soon!
--Mark
Mark Foley
Jul 20, 2016, 1:30:04 PM7/20/16
to
Mike, excellent suggestion! I will definitely experiment with that nsswitch change. Rowland
also mentioned adding RFC2307 to the AD settings for the user(s).
If, as you say, my MTA will find the home directory with the nss windbind setting, that would
be fantastic! I would definitely removed the AD users from /etc/passwd.
I don't know if nsswitch.conf settings are now mentioned in the wiki, but they certainly
weren't there (that I found) in August, 2014 when I configured my Samba4 AD/DC. If this works,
this would be another important thing to put in the wiki.
I did configure a domain member with winbind in the nsswitch.conf, but those settings were
explicitly given to me by Rowland last summer, 2015 in our maillist correspondence on single
sign on (see past thread, subject contains "Single-Sign-On". Based on our discussion and my
successfully setting up a Linux domain member workstation, that wiki
(https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member) does now have the
nsswitch.conf info for winbind.
Thanks for the idea. I'll post back results.
--Mark
-----Original Message-----
> From: Data Control Systems - Mike Elkevizth <mi...@datacontrolsystems.com>
> Date: Sun, 17 Jul 2016 13:35:27 +0000
> To: Rowland penny <rpe...@samba.org>, sa...@lists.samba.org
> Subject: Re: [Samba] How to GSSAPI/Kerberos authenticate with Dovecot
> [formerly Where is krb5.keytab or equivalent?]
>
also mentioned adding RFC2307 to the AD settings for the user(s).
If, as you say, my MTA will find the home directory with the nss windbind setting, that would
be fantastic! I would definitely removed the AD users from /etc/passwd.
I don't know if nsswitch.conf settings are now mentioned in the wiki, but they certainly
weren't there (that I found) in August, 2014 when I configured my Samba4 AD/DC. If this works,
this would be another important thing to put in the wiki.
I did configure a domain member with winbind in the nsswitch.conf, but those settings were
explicitly given to me by Rowland last summer, 2015 in our maillist correspondence on single
sign on (see past thread, subject contains "Single-Sign-On". Based on our discussion and my
successfully setting up a Linux domain member workstation, that wiki
(https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member) does now have the
nsswitch.conf info for winbind.
Thanks for the idea. I'll post back results.
--Mark
-----Original Message-----
> From: Data Control Systems - Mike Elkevizth <mi...@datacontrolsystems.com>
> Date: Sun, 17 Jul 2016 13:35:27 +0000
> To: Rowland penny <rpe...@samba.org>, sa...@lists.samba.org
> Subject: Re: [Samba] How to GSSAPI/Kerberos authenticate with Dovecot
> [formerly Where is krb5.keytab or equivalent?]
>
Rowland penny
Jul 20, 2016, 1:40:03 PM7/20/16
to
On 20/07/16 18:05, Mark Foley wrote:
> On Sun, 17 Jul 2016 08:32:28 +0100 Rowland penny <rpe...@samba.org> wrote:
> I will absolutely check this out! If I can do what I need without actually adding the user to
> /etc/passwd, that would be great. I'll post back results.
>
>> In your setup you could have a user 'USERA' in AD and on your mail
>> computer you could also have a 'USERA' in /etc/passwd,
> Well, that's basically what I have! :) It's just the mail computer *is* the AD/DC.
>
>> how do you keep the password for the two users in sync ? what happens if the AD
>> user changes their password ?
> They don't need to keep the passwords in sync since the AD password is the only one used for
> authentication. Users never log onto the AD/DC directly, certainly not at the command line.
> User logging into domain members, Linux or Windows, command line or not, use their AD
> credentials. Their /etc/passwd password on the DC in never involved.
>
> The DC's /etc/password entries are used solely for Sendmail/procmail to deliver mail to the
> user's target email folders.
OK, here is an idea, you only use /etc/passwd for sendmail/procmail, so
> On Sun, 17 Jul 2016 08:32:28 +0100 Rowland penny <rpe...@samba.org> wrote:
> I will absolutely check this out! If I can do what I need without actually adding the user to
> /etc/passwd, that would be great. I'll post back results.
>
>> In your setup you could have a user 'USERA' in AD and on your mail
>> computer you could also have a 'USERA' in /etc/passwd,
> Well, that's basically what I have! :) It's just the mail computer *is* the AD/DC.
>
>> how do you keep the password for the two users in sync ? what happens if the AD
>> user changes their password ?
> They don't need to keep the passwords in sync since the AD password is the only one used for
> authentication. Users never log onto the AD/DC directly, certainly not at the command line.
> User logging into domain members, Linux or Windows, command line or not, use their AD
> credentials. Their /etc/passwd password on the DC in never involved.
>
> The DC's /etc/password entries are used solely for Sendmail/procmail to deliver mail to the
> user's target email folders.
don't use sendmail or procmail !
What, I hear you say, what do I use instead ? Did you know Dovecot can
deliver mail to a mailbox ?
>
> It's kind of analogous to `samba-tool user create dovecot --ramdom-password`. The idea is
> simply to create an entry.
>
> Having said that, if the user would need to sync or change their /etc/passwd password I have
> provided an application for them to do that which uses chpasswd on the AD/DC. This also
> updates the Apache passwords (if any). This mechanism has not been needed in the 2 years since
> I created it.
you have somewhere to store plain or ssha etc passwords (which is
another point of entry to your systems), you are going to have problems.
>> My systems are setup correctly and I cannot create a local Unix user if
>> the user exists in AD, ...
> Well, perhaps a later version of Samba adds this check (I have 4.2.12). I really did nothing
> special to my samba set up. I followed the wiki for the smb.conf exactly. Samba itself came
> with my distro, no building needed on my part.
>
>> but this doesn't matter, because I do not need to. If I want an AD user to also be a Unix
>> user, I just add the required RFC2307 attributes to the users object in AD.
>>
>> If I run this command on a Unix domain member:
>>
>> rowland@devstation:~$ cat /etc/passwd | grep rowland
>> rowland@devstation:~$
>>
>> I get nothing returned, so the user 'rowland' doesn't exist in
>> /etc/passwd, but if I then run this command:
>>
>> rowland@devstation:~$ getent passwd rowland
>> rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
>>
>> Funny, I seem to have a Unix user called 'rowland', but he doesn't exist
>> in /etc/passwd and if I wanted to use this user with Dovecot, I could.
>>
>> Rowland
> Right, dovecot does not need the /etc/passwd now that I've implemented gssapi authentication
> (it did use it before with the PLAIN auth method). As I said, that entry is there soley for
> Sendmail/procmail to locate the user's target email folders. If sendmail could AD authenticate
> I wouldn't need /etc/passwd at all.
>
> I'll definately check out that RFC2307 to see if that would takes care of the sendmail issue
> and I'll post back my findings.
>
> And before anyone asks ... no, we're not likely to get rid of sendmail any time soon!
the programs you are using can do the same thing.
Rowland
Mark Foley
Jul 21, 2016, 1:20:03 AM7/21/16
to
OK! I deleted the /etc/passwd entry for user mark and I modified my /etc/nsswitch.conf to:
passwd: compat winbind
group: compat winbind
I couldn't get sendmail working with this at first -- I didn't know what to [re]start to get
the new nsswitch config to take, so I rebooted. Probably I just had to restart sendmail, but oh
well.
And, it started working ... sort of. Email to that user was delivered OK; meaning
sendmail/procmail were able to find the right IMAP folder to deliver mail.
However, email from that sender is not working and I'm sure one of you geniuses can set me
straight. Here's my getent before deleting the /etc/passwd entry and before nsswitch changes:
$ getent passwd mark
mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash
... and after the changes:
$ getent passwd mark
HPRS\mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/false
See the difference? And here are a few mail log messages:
Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: Authentication-Warning: mail.hprs.local: HPRS\\mark set sender to @ohprs.org using -r
Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: @ohprs.org... User address required
Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: from="HPRS\\\\mark",
Notice that it is now getting the userID as "HPRS\mark", i.e. domain\user, and the from address
ends up being HPRS\ma...@ohprs.org, which sendmail is not handling well.
Any ideas how to fix that?
I'll check with the sendmail people also.
Almost there! When I get this sorted out, I can remove my AD users from /etc/passwd which
should make Roland happy!
--Mark
passwd: compat winbind
group: compat winbind
the new nsswitch config to take, so I rebooted. Probably I just had to restart sendmail, but oh
well.
And, it started working ... sort of. Email to that user was delivered OK; meaning
sendmail/procmail were able to find the right IMAP folder to deliver mail.
However, email from that sender is not working and I'm sure one of you geniuses can set me
straight. Here's my getent before deleting the /etc/passwd entry and before nsswitch changes:
$ getent passwd mark
mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash
... and after the changes:
$ getent passwd mark
HPRS\mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/false
See the difference? And here are a few mail log messages:
Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: Authentication-Warning: mail.hprs.local: HPRS\\mark set sender to @ohprs.org using -r
Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: @ohprs.org... User address required
Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: from="HPRS\\\\mark",
Notice that it is now getting the userID as "HPRS\mark", i.e. domain\user, and the from address
ends up being HPRS\ma...@ohprs.org, which sendmail is not handling well.
Any ideas how to fix that?
I'll check with the sendmail people also.
Almost there! When I get this sorted out, I can remove my AD users from /etc/passwd which
should make Roland happy!
--Mark
Rowland penny
Jul 21, 2016, 4:00:03 AM7/21/16
to
On 21/07/16 06:08, Mark Foley wrote:
> OK! I deleted the /etc/passwd entry for user mark and I modified my /etc/nsswitch.conf to:
>
> passwd: compat winbind
> group: compat winbind
>
> I couldn't get sendmail working with this at first -- I didn't know what to [re]start to get
> the new nsswitch config to take, so I rebooted. Probably I just had to restart sendmail, but oh
> well.
>
> And, it started working ... sort of. Email to that user was delivered OK; meaning
> sendmail/procmail were able to find the right IMAP folder to deliver mail.
>
> However, email from that sender is not working and I'm sure one of you geniuses can set me
> straight. Here's my getent before deleting the /etc/passwd entry and before nsswitch changes:
>
> $ getent passwd mark
> mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash
>
> ... and after the changes:
>
> $ getent passwd mark
> HPRS\mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/false
OK, you are running into one of the problems of using a DC as a
> OK! I deleted the /etc/passwd entry for user mark and I modified my /etc/nsswitch.conf to:
>
> passwd: compat winbind
> group: compat winbind
>
> I couldn't get sendmail working with this at first -- I didn't know what to [re]start to get
> the new nsswitch config to take, so I rebooted. Probably I just had to restart sendmail, but oh
> well.
>
> And, it started working ... sort of. Email to that user was delivered OK; meaning
> sendmail/procmail were able to find the right IMAP folder to deliver mail.
>
> However, email from that sender is not working and I'm sure one of you geniuses can set me
> straight. Here's my getent before deleting the /etc/passwd entry and before nsswitch changes:
>
> $ getent passwd mark
> mark:x:10001:10000:Mark Foley:/home/HPRS/mark:/bin/bash
>
> ... and after the changes:
>
> $ getent passwd mark
> HPRS\mark:*:10001:10000:Mark Foley:/home/HPRS/mark:/bin/false
fileserver here, the only RFC2307 attributes used from AD are
'uidNumber' & 'gidNumber'. You can get around the users home placement
and shell with a couple of lines in smb.conf:
template homedir = /home/%U
template shell = /bin/bash
Restart Samba
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.
Rowland
>
> See the difference? And here are a few mail log messages:
>
> Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: Authentication-Warning: mail.hprs.local: HPRS\\mark set sender to @ohprs.org using -r
> Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: @ohprs.org... User address required
> Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: from="HPRS\\\\mark",
>
> Notice that it is now getting the userID as "HPRS\mark", i.e. domain\user, and the from address
> ends up being HPRS\ma...@ohprs.org, which sendmail is not handling well.
>
> Any ideas how to fix that?
>
> I'll check with the sendmail people also.
>
> Almost there! When I get this sorted out, I can remove my AD users from /etc/passwd which
> should make Roland happy!
>
> --Mark
>
>
> See the difference? And here are a few mail log messages:
>
> Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: Authentication-Warning: mail.hprs.local: HPRS\\mark set sender to @ohprs.org using -r
> Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: @ohprs.org... User address required
> Jul 21 00:46:35 mail sendmail[15987]: u6L4kZms015987: from="HPRS\\\\mark",
>
> Notice that it is now getting the userID as "HPRS\mark", i.e. domain\user, and the from address
> ends up being HPRS\ma...@ohprs.org, which sendmail is not handling well.
>
> Any ideas how to fix that?
>
> I'll check with the sendmail people also.
>
> Almost there! When I get this sorted out, I can remove my AD users from /etc/passwd which
> should make Roland happy!
>
> --Mark
>
>
Mark Foley
Jul 21, 2016, 11:00:04 AM7/21/16
to
> Date: Thu, 21 Jul 2016 08:56:54 +0100
> From: Rowland penny <rpe...@samba.org>
Actually, the homedir is fine, though that's a good setting to know. I did add the "template
shell" and that worked, but I don't really care about the shell (yet) since this is not a
computer people log onto.
Anyway, the problem is that getent is apparently returning HPRS\mark as the user to sendmail,
and sendmail is constructing the outgoing email address as HPRS\ma...@ohprs.org -- which is bad.
I already have "winbind use default domain = yes".
Maybe I need a rewrite rule in sendmail.
btw - I've changed the subject line. This is not about gssapi/kerberos.
--Mark
> From: Rowland penny <rpe...@samba.org>
shell" and that worked, but I don't really care about the shell (yet) since this is not a
computer people log onto.
Anyway, the problem is that getent is apparently returning HPRS\mark as the user to sendmail,
and sendmail is constructing the outgoing email address as HPRS\ma...@ohprs.org -- which is bad.
I already have "winbind use default domain = yes".
Maybe I need a rewrite rule in sendmail.
btw - I've changed the subject line. This is not about gssapi/kerberos.
--Mark
Data Control Systems - Mike Elkevizth
Jul 21, 2016, 12:40:04 PM7/21/16
to
Hi Mark,
I've had the same trouble with the DOMAIN\user on my DCs, and as Rowland
has already pointed out, the "winbind use default domain = yes" configure
option is not honored on a DC. My guess is that is because a Samba DC can
only be a DC for one domain, so that is why it isn't honored. If I do
"getent passwd username" on my DCs, they all return
"DOMAIN\username:*:uidNumber:gidNumber:User
Name:/home/DOMAIN/username:/login/shell" which is the same thing as "getent
passwd 'DOMAIN\username'" returns. So you can probably change the
configuration of sendmail to drop the "DOMAIN\" from the start of the
username, although I'm not sure how to do that. The other option would be
to not use winbind, and to instead use sssd. I've not tried this on a DC,
but I can't see why it wouldn't work. You would have to remove winbind
from your nsswitch config and add the sssd entries. Mine looks like this
on my domain members:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat sss
group: compat sss
shadow: compat sss
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files sss
ethers: db files
rpc: db files
netgroup: nis sss
sudoers: files sss
My /etc/sssd/sssd.conf looks like this:
[sssd]
services = nss, pam
config_file_version = 2
domains = AD.REALM
[domain/AD.REALM]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
# Set to false if you want to use POSIX UIDs and GIDs set on the AD side
ldap_id_mapping = False
# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.
enumerate = true
# Allow offline logins by locally storing password hashes (default: false).
#cache_credentials = true
This might be easier than trying to change the sendmail configuration or
figuring out the "the idiosyncrasies in the winbindd configuration on the
Active Directory Domain Controller" as described on the Samba wiki
https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Introduction
Mike E.
I've had the same trouble with the DOMAIN\user on my DCs, and as Rowland
has already pointed out, the "winbind use default domain = yes" configure
option is not honored on a DC. My guess is that is because a Samba DC can
only be a DC for one domain, so that is why it isn't honored. If I do
"getent passwd username" on my DCs, they all return
"DOMAIN\username:*:uidNumber:gidNumber:User
Name:/home/DOMAIN/username:/login/shell" which is the same thing as "getent
passwd 'DOMAIN\username'" returns. So you can probably change the
configuration of sendmail to drop the "DOMAIN\" from the start of the
username, although I'm not sure how to do that. The other option would be
to not use winbind, and to instead use sssd. I've not tried this on a DC,
but I can't see why it wouldn't work. You would have to remove winbind
from your nsswitch config and add the sssd entries. Mine looks like this
on my domain members:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat sss
group: compat sss
shadow: compat sss
gshadow: files
hosts: files dns
networks: files
services: db files sss
ethers: db files
rpc: db files
netgroup: nis sss
sudoers: files sss
My /etc/sssd/sssd.conf looks like this:
[sssd]
services = nss, pam
config_file_version = 2
domains = AD.REALM
[domain/AD.REALM]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
# Set to false if you want to use POSIX UIDs and GIDs set on the AD side
ldap_id_mapping = False
# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.
enumerate = true
# Allow offline logins by locally storing password hashes (default: false).
#cache_credentials = true
This might be easier than trying to change the sendmail configuration or
figuring out the "the idiosyncrasies in the winbindd configuration on the
Active Directory Domain Controller" as described on the Samba wiki
https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Introduction
Mike E.
Mark Foley
Jul 21, 2016, 4:40:02 PM7/21/16
to
Thanks Mike. I'll investigate ssd although it shouldn't be too hard to have sendmail rewrite
the userID to remove the domain. I'm investigating this now and will post results.
--Mark
-----Original Message-----
> From: Data Control Systems - Mike Elkevizth <mi...@datacontrolsystems.com>
the userID to remove the domain. I'm investigating this now and will post results.
--Mark
-----Original Message-----
> From: Data Control Systems - Mike Elkevizth <mi...@datacontrolsystems.com>
Mark Foley
Jul 25, 2016, 10:30:03 AM7/25/16
to
Mike,
If the DC returns "DOMAIN\username", but domain members (correctly?) return just "username", is
this a bug in the DC? Is there some reason the DC essentially ignores the "winbind use default
domain = yes" and returns DOMAIN\username? It would seem to me that sendmail would not be the
only program stumbling on this.
If the DC returns "DOMAIN\username", but domain members (correctly?) return just "username", is
this a bug in the DC? Is there some reason the DC essentially ignores the "winbind use default
domain = yes" and returns DOMAIN\username? It would seem to me that sendmail would not be the
only program stumbling on this.
Mark Foley
Jul 25, 2016, 10:40:03 AM7/25/16
to
Dewayne,
Thanks a lot for this patch. I'll hang on to it any probably do some experimenting on the side.
The problem with this approach is that our AD/DC/Mail-server is in an office and I have to be
concerned about future sysadmins as well as future sendmail updates. I am very reluctant to
patch OS software, especially if other solutions are available.
At worst, I can drop back and remove winbind from nsswitch.conf on the AD and put the user back
in /etc/passwd. That's how I've been running for nearly 2 years and it's worked just fine. I
was hoping to eliminate dual-entries for users in AD and passwd, but that's easier for someone
to sort out than a patch.
What I'd really like is a sendmail rule that would simply strip the "HPRS\" bit off the front
of the username token. It seems like a rather simple rule (if there are such things in
sendmail!), but I've found nothing so far and no feedback from expert sites. I could put this
rule in my .mc file so it would be both documented and be independent of sendmail program updates.
I subscribed to the sendmail...@lists.sendmail.org maillist but the moderator hasn't even
"approved" my initial post yet. It might be a dead list.
Any ideas on resources for this?
--Mark
-----Original Message-----
> From: Dewayne Geraghty <dewayne...@gmail.com>
> Date: Sat, 23 Jul 2016 18:39:32 +1000
> Subject: Re: [Samba] sendmail getting domain\user as email userId [formerly:
> How to GSSAPI/Kerberos authenticate with Dovecot]
> To: Mark Foley <mfo...@ohprs.org>
>
> Mark,
> We've had this problem with sendmail in 2014. A friend John Marshall
> addressed this on FreeBSD. I've included a patch that may assist. The
> patch applies cleanly, though with the cut/paste between my ssh session and
> this windows client, the spacing may be incorrect.
>
> This is a known to sendmail bug, but they were unprepared to rectify.
>
> --- sendmail/srvrsmtp.c.orig 2013-11-23 07:51:56.000000000 +1100
> +++ sendmail/srvrsmtp.c 2014-01-27 17:26:30.000000000 +1100
> @@ -84,7 +84,7 @@
> # define RESET_SASLCONN \
> do \
> { \
> - result = reset_saslconn(&conn, AuthRealm, remoteip, \
> + result = reset_saslconn(&conn, hostname, remoteip, \
> localip, auth_id, &ext_ssf); \
> if (result != SASL_OK) \
> sasl_ok = false; \
> @@ -761,8 +761,8 @@
> if (sasl_ok)
> {
> # if SASL >= 20000
> - result = sasl_server_new("smtp", AuthRealm, NULL, NULL,
> NULL,
> - NULL, 0, &conn);
> + result = sasl_server_new("smtp", hostname, AuthRealm, NULL,
> + NULL, NULL, 0, &conn);
> # elif SASL > 10505
> /* use empty realm: only works in SASL > 1.5.5 */
> result = sasl_server_new("smtp", AuthRealm, "", NULL, 0,
> &conn);
> @@ -5027,7 +5027,7 @@
>
> sasl_dispose(conn);
> # if SASL >= 20000
> - result = sasl_server_new("smtp", hostname, NULL, NULL, NULL,
> + result = sasl_server_new("smtp", hostname, AuthRealm, NULL, NULL,
> NULL, 0, conn);
> # elif SASL > 10505
> /* use empty realm: only works in SASL > 1.5.5 */
> --
> *Disclaimer:*
>
>
>
> *As implied by email protocols, the information in this message is not
> confidential. Any intermediary or recipient may inspect, modify (add),
> copy, forward, reply to, delete, or filter email for any purpose unless
> said parties are otherwise obligated. Nothing in this message may be
> legally binding without cryptographic evidence of its integrity and/or
> confidentiality.*
Thanks a lot for this patch. I'll hang on to it any probably do some experimenting on the side.
The problem with this approach is that our AD/DC/Mail-server is in an office and I have to be
concerned about future sysadmins as well as future sendmail updates. I am very reluctant to
patch OS software, especially if other solutions are available.
At worst, I can drop back and remove winbind from nsswitch.conf on the AD and put the user back
in /etc/passwd. That's how I've been running for nearly 2 years and it's worked just fine. I
was hoping to eliminate dual-entries for users in AD and passwd, but that's easier for someone
to sort out than a patch.
What I'd really like is a sendmail rule that would simply strip the "HPRS\" bit off the front
of the username token. It seems like a rather simple rule (if there are such things in
sendmail!), but I've found nothing so far and no feedback from expert sites. I could put this
rule in my .mc file so it would be both documented and be independent of sendmail program updates.
I subscribed to the sendmail...@lists.sendmail.org maillist but the moderator hasn't even
"approved" my initial post yet. It might be a dead list.
Any ideas on resources for this?
--Mark
-----Original Message-----
> From: Dewayne Geraghty <dewayne...@gmail.com>
> Date: Sat, 23 Jul 2016 18:39:32 +1000
> Subject: Re: [Samba] sendmail getting domain\user as email userId [formerly:
> How to GSSAPI/Kerberos authenticate with Dovecot]
> To: Mark Foley <mfo...@ohprs.org>
>
> We've had this problem with sendmail in 2014. A friend John Marshall
> addressed this on FreeBSD. I've included a patch that may assist. The
> patch applies cleanly, though with the cut/paste between my ssh session and
> this windows client, the spacing may be incorrect.
>
> This is a known to sendmail bug, but they were unprepared to rectify.
>
> --- sendmail/srvrsmtp.c.orig 2013-11-23 07:51:56.000000000 +1100
> +++ sendmail/srvrsmtp.c 2014-01-27 17:26:30.000000000 +1100
> @@ -84,7 +84,7 @@
> # define RESET_SASLCONN \
> do \
> { \
> - result = reset_saslconn(&conn, AuthRealm, remoteip, \
> + result = reset_saslconn(&conn, hostname, remoteip, \
> localip, auth_id, &ext_ssf); \
> if (result != SASL_OK) \
> sasl_ok = false; \
> @@ -761,8 +761,8 @@
> if (sasl_ok)
> {
> # if SASL >= 20000
> - result = sasl_server_new("smtp", AuthRealm, NULL, NULL,
> NULL,
> - NULL, 0, &conn);
> + result = sasl_server_new("smtp", hostname, AuthRealm, NULL,
> + NULL, NULL, 0, &conn);
> # elif SASL > 10505
> /* use empty realm: only works in SASL > 1.5.5 */
> result = sasl_server_new("smtp", AuthRealm, "", NULL, 0,
> &conn);
> @@ -5027,7 +5027,7 @@
>
> sasl_dispose(conn);
> # if SASL >= 20000
> - result = sasl_server_new("smtp", hostname, NULL, NULL, NULL,
> + result = sasl_server_new("smtp", hostname, AuthRealm, NULL, NULL,
> NULL, 0, conn);
> # elif SASL > 10505
> /* use empty realm: only works in SASL > 1.5.5 */
> *Disclaimer:*
>
>
>
> *As implied by email protocols, the information in this message is not
> confidential. Any intermediary or recipient may inspect, modify (add),
> copy, forward, reply to, delete, or filter email for any purpose unless
> said parties are otherwise obligated. Nothing in this message may be
> legally binding without cryptographic evidence of its integrity and/or
> confidentiality.*
Rowland penny
Jul 25, 2016, 11:40:02 AM7/25/16
to
On 25/07/16 15:22, Mark Foley wrote:
> Mike,
>
> If the DC returns "DOMAIN\username", but domain members (correctly?) return just "username", is
> this a bug in the DC? Is there some reason the DC essentially ignores the "winbind use default
> domain = yes" and returns DOMAIN\username? It would seem to me that sendmail would not be the
> only program stumbling on this.
>
> --Mark
>
>
The problem isn't that the DC returns 'DOMAIN\username' , it is that
> Mike,
>
> If the DC returns "DOMAIN\username", but domain members (correctly?) return just "username", is
> this a bug in the DC? Is there some reason the DC essentially ignores the "winbind use default
> domain = yes" and returns DOMAIN\username? It would seem to me that sendmail would not be the
> only program stumbling on this.
>
> --Mark
>
>
adding 'winbind use default domain = yes' to smb.conf on the DC doesn't
work. Without this line on a domain member, winbind returns the same
result as on a DC i.e. DOMAIN\username. The further problem is that
whilst the Samba devs are aware of this, they have other things to
fix/make work and this comes low down on the scale.
If you can program in 'C', I am sure a Patch to fix your problem would
be welcomed.
Rowland
Data Control Systems - Mike Elkevizth
Jul 25, 2016, 11:40:03 AM7/25/16
to
Hi Mark,
I'm not sure why a DC ignores the "winbind use default domain = yes"
setting. Its not the only setting that a DC ignores and the only real hint
of DCs acting weird is the line in the introduction of the wiki about
setting Samba up as a DC that calls these "idiosyncrasies in the winbindd
configuration on the Active Directory Domain Controller." Since it seems
to be a well known issue, I haven't ever filed a bug report against it.
I'm guessing the Samba devs have a reason for these "idiosyncrasies", but
maybe it would be worth filing a bug report and that may shed some more
light on why it is, or has to be.
Being a lowly system admin, I just try to work around the issues I run
into, and that's why I suggested using sssd instead of winbind for the user
enumeration. It (sssd) does drop the domain from the username (at least on
a member server it does) and so I think it would work for your situation.
Maybe one of the Samba devs can chime in on the "why" things seem to be so
different for a DC.?
Mike E.
I'm not sure why a DC ignores the "winbind use default domain = yes"
setting. Its not the only setting that a DC ignores and the only real hint
of DCs acting weird is the line in the introduction of the wiki about
setting Samba up as a DC that calls these "idiosyncrasies in the winbindd
configuration on the Active Directory Domain Controller." Since it seems
to be a well known issue, I haven't ever filed a bug report against it.
I'm guessing the Samba devs have a reason for these "idiosyncrasies", but
maybe it would be worth filing a bug report and that may shed some more
light on why it is, or has to be.
Being a lowly system admin, I just try to work around the issues I run
into, and that's why I suggested using sssd instead of winbind for the user
enumeration. It (sssd) does drop the domain from the username (at least on
a member server it does) and so I think it would work for your situation.
Maybe one of the Samba devs can chime in on the "why" things seem to be so
different for a DC.?
Mike E.
Rowland penny
Jul 25, 2016, 12:10:03 PM7/25/16
to
On 25/07/16 16:31, Data Control Systems - Mike Elkevizth wrote:
> Hi Mark,
>
> I'm not sure why a DC ignores the "winbind use default domain = yes"
> setting. Its not the only setting that a DC ignores and the only real hint
> of DCs acting weird is the line in the introduction of the wiki about
> setting Samba up as a DC that calls these "idiosyncrasies in the winbindd
> configuration on the Active Directory Domain Controller." Since it seems
> to be a well known issue, I haven't ever filed a bug report against it.
> I'm guessing the Samba devs have a reason for these "idiosyncrasies", but
> maybe it would be worth filing a bug report and that may shed some more
> light on why it is, or has to be.
There is already a bug report for this:
> Hi Mark,
>
> I'm not sure why a DC ignores the "winbind use default domain = yes"
> setting. Its not the only setting that a DC ignores and the only real hint
> of DCs acting weird is the line in the introduction of the wiki about
> setting Samba up as a DC that calls these "idiosyncrasies in the winbindd
> configuration on the Active Directory Domain Controller." Since it seems
> to be a well known issue, I haven't ever filed a bug report against it.
> I'm guessing the Samba devs have a reason for these "idiosyncrasies", but
> maybe it would be worth filing a bug report and that may shed some more
> light on why it is, or has to be.
https://bugzilla.samba.org/show_bug.cgi?id=9780
>
> Being a lowly system admin, I just try to work around the issues I run
> into, and that's why I suggested using sssd instead of winbind for the user
> enumeration. It (sssd) does drop the domain from the username (at least on
> a member server it does) and so I think it would work for your situation.
>
> Maybe one of the Samba devs can chime in on the "why" things seem to be so
> different for a DC.?
Rowland
> Mike E.
Mark Foley
Jul 26, 2016, 4:50:03 PM7/26/16
to
Well, ladies and gentlemen -- it's now working! Sendmail *is* authenticating with the
nsswitch.conf settings (winbind added):
passwd: compat winbind
shadow: compat winbind
group: compat winbind
and with the AD user REMOVED from /etc/passwd. All is well. I did nothing, no patching of
sendmail, no username rewrite rule in sendmail.[mc|cf].
I can't really explain what changed. Perhaps restarting sendmail and/or samba? I don't
remember. I didn't reboot, but samba is automatically stopped/started during a wee-hours daily
backup and is also restarted weekly by logrotate. I did modify /etc/mail/aliases for unrelated
reasons and restarted sendmail thereafter.
I'm guessing that restarting one or both of these programs did the trick. I should follow my
own advice to my users: try rebooting first! It solves a world of problems.
So, Mr. Penny, you will be pleased to know that henceforth I WILL NOT have AD users also in
/etc/passwd (well, except for 2 Outlook stragglers for whom I've not yet figured out how to
dovecot NTLM authenticate ... working on it; unless I can get them to switch the Thunderbird
first!).
I've not checked the documentation, but I would suggest adding the winbind settings to the docs
for the AD/DC setup wiki, if missing. You explictly gave me those settings for configuring a
domain member for single-sign-on last year, and I believe you incorporated that info into the
domain member wiki.
Being able to authenticate *on* the AC/DC does not necessarily imply its use as a file server.
Programs should be able to authenticate when running on the AC/DC.
Thanks!!! --Mark
-----Original Message-----
> To: sa...@lists.samba.org
> From: Rowland penny <rpe...@samba.org>
> Date: Mon, 25 Jul 2016 16:59:36 +0100
> Subject: Re: [Samba] sendmail getting domain\user as email userId
>
nsswitch.conf settings (winbind added):
passwd: compat winbind
shadow: compat winbind
group: compat winbind
and with the AD user REMOVED from /etc/passwd. All is well. I did nothing, no patching of
sendmail, no username rewrite rule in sendmail.[mc|cf].
I can't really explain what changed. Perhaps restarting sendmail and/or samba? I don't
remember. I didn't reboot, but samba is automatically stopped/started during a wee-hours daily
backup and is also restarted weekly by logrotate. I did modify /etc/mail/aliases for unrelated
reasons and restarted sendmail thereafter.
I'm guessing that restarting one or both of these programs did the trick. I should follow my
own advice to my users: try rebooting first! It solves a world of problems.
So, Mr. Penny, you will be pleased to know that henceforth I WILL NOT have AD users also in
/etc/passwd (well, except for 2 Outlook stragglers for whom I've not yet figured out how to
dovecot NTLM authenticate ... working on it; unless I can get them to switch the Thunderbird
first!).
I've not checked the documentation, but I would suggest adding the winbind settings to the docs
for the AD/DC setup wiki, if missing. You explictly gave me those settings for configuring a
domain member for single-sign-on last year, and I believe you incorporated that info into the
domain member wiki.
Being able to authenticate *on* the AC/DC does not necessarily imply its use as a file server.
Programs should be able to authenticate when running on the AC/DC.
Thanks!!! --Mark
-----Original Message-----
> To: sa...@lists.samba.org
> From: Rowland penny <rpe...@samba.org>
> Date: Mon, 25 Jul 2016 16:59:36 +0100
> Subject: Re: [Samba] sendmail getting domain\user as email userId
>
Rowland penny
Jul 26, 2016, 5:20:03 PM7/26/16
to
As for the info you would like adding to the wiki, it used to be there,
but when the wiki was re-written, it was removed. The thinking seemed to
be, as samba doesn't recommend using the DC as a fileserver, it
shouldn't be there. Samba has been recommending not using the DC as a
fileserver since version 4 was first released, this was nearly 4 years
ago. Perhaps, due to the many changes since the first release, it is
time to reconsider this recommendation.
Rowland
Mark Foley
Jul 28, 2016, 1:40:03 AM7/28/16
to
Since you bring up that topic (Samba4 not recommended as a file server), I've been meaning to
ask on this list for a while: Why?
I installed Samba4 2 years ago next month. I read then that recommendation in the wiki and
took it literaly: not actual Samba shares. I followed the advice and we have two other
different servers acting as actual "classic" Samba file servers. At the time, I did not take
that recommendation to mean that hosting a mail server and the like were included.
Therefore, I blithely went ahead and set up Samba4 as a full-on replacement for our retiring
Windows SBS 2008 AD/DC. That included AD authentication, mail server (with sendmail/dovecot
replacing Exchange), Remote Desktop Connection (policy), redirected folders (certainly file
server-like), DNS, DHCP, webmail, iCal calendar server ... and probably a bunch of stuff I'm
not thinking about at the moment. When I figured out the various configs for the various
services (not too hard, really, except for a long stretch trying to figure out Dovecot
authentication), everything just worked, perfectly. We've been running production for more than
a year and a half with WIN7 workstations in user offices and a couple of experimental Linux
domain member workstations. We've never had a hiccup, never lost a file that I'm aware of and
have had zero problems with Samba4 doing all this -- which is more than I can say for good 'ole
SBS2008 in its day.
All that said to demonstrate that we've been using Samba4 for supposedly "not recommended"
purposes in a real production environment for quite a while. Furthermore, outfits like Zentyal
must be doing the same.
So, to repeat the main question: Why is Samba4 not recommended for this sort of thing? I've
not come across actual reasons. Maybe too bit-specific technical for this list, but I like
someone to at least speculate on the reason. I'm curious.
--Mark
-----Original Message-----
> To: sa...@lists.samba.org
> From: Rowland penny <rpe...@samba.org>
> Date: Tue, 26 Jul 2016 22:13:43 +0100
> Subject: Re: [Samba] sendmail getting domain\user as email userId
>
[delted]
ask on this list for a while: Why?
I installed Samba4 2 years ago next month. I read then that recommendation in the wiki and
took it literaly: not actual Samba shares. I followed the advice and we have two other
different servers acting as actual "classic" Samba file servers. At the time, I did not take
that recommendation to mean that hosting a mail server and the like were included.
Therefore, I blithely went ahead and set up Samba4 as a full-on replacement for our retiring
Windows SBS 2008 AD/DC. That included AD authentication, mail server (with sendmail/dovecot
replacing Exchange), Remote Desktop Connection (policy), redirected folders (certainly file
server-like), DNS, DHCP, webmail, iCal calendar server ... and probably a bunch of stuff I'm
not thinking about at the moment. When I figured out the various configs for the various
services (not too hard, really, except for a long stretch trying to figure out Dovecot
authentication), everything just worked, perfectly. We've been running production for more than
a year and a half with WIN7 workstations in user offices and a couple of experimental Linux
domain member workstations. We've never had a hiccup, never lost a file that I'm aware of and
have had zero problems with Samba4 doing all this -- which is more than I can say for good 'ole
SBS2008 in its day.
All that said to demonstrate that we've been using Samba4 for supposedly "not recommended"
purposes in a real production environment for quite a while. Furthermore, outfits like Zentyal
must be doing the same.
So, to repeat the main question: Why is Samba4 not recommended for this sort of thing? I've
not come across actual reasons. Maybe too bit-specific technical for this list, but I like
someone to at least speculate on the reason. I'm curious.
--Mark
-----Original Message-----
> To: sa...@lists.samba.org
> From: Rowland penny <rpe...@samba.org>
> Date: Tue, 26 Jul 2016 22:13:43 +0100
> Subject: Re: [Samba] sendmail getting domain\user as email userId
>
John Gardeniers
Jul 28, 2016, 2:00:02 AM7/28/16
to
Hi Mark,
You may have misunderstood. It's only the Samba 4 domain controllers
that shouldn't be used as file servers. A regular server, whether domain
member or free- standing, works perfectly as a file server.
regards,
John
You may have misunderstood. It's only the Samba 4 domain controllers
that shouldn't be used as file servers. A regular server, whether domain
member or free- standing, works perfectly as a file server.
regards,
John
Olivier
Jul 28, 2016, 2:10:02 AM7/28/16
to
Mark Foley <mfo...@ohprs.org> writes:
> Since you bring up that topic (Samba4 not recommended as a file server), I've been meaning to
> ask on this list for a while: Why?
> [...]
> Since you bring up that topic (Samba4 not recommended as a file server), I've been meaning to
> ask on this list for a while: Why?
>> As for the info you would like adding to the wiki, it used to be there,
>> but when the wiki was re-written, it was removed. The thinking seemed to
>> be, as samba doesn't recommend using the DC as a fileserver, it
>> shouldn't be there. Samba has been recommending not using the DC as a
What was said is "not using the DC as file server", not "not using
>> but when the wiki was re-written, it was removed. The thinking seemed to
>> be, as samba doesn't recommend using the DC as a fileserver, it
>> shouldn't be there. Samba has been recommending not using the DC as a
Samba".
My understanding is that it is better to have one machine running the DC
and another serving files.
Best regards,
Olivier
Michael Adam
Jul 28, 2016, 2:50:03 AM7/28/16
to
On 2016-07-28 at 12:43 +0700, Olivier wrote:
> Mark Foley <mfo...@ohprs.org> writes:
>
> > Since you bring up that topic (Samba4 not recommended as a file server), I've been meaning to
> > ask on this list for a while: Why?
> > [...]
> >> As for the info you would like adding to the wiki, it used to be there,
> >> but when the wiki was re-written, it was removed. The thinking seemed to
> >> be, as samba doesn't recommend using the DC as a fileserver, it
> >> shouldn't be there. Samba has been recommending not using the DC as a
>
> What was said is "not using the DC as file server", not "not using
> Samba".
>
> My understanding is that it is better to have one machine running the DC
> and another serving files.
Exactly.
> Mark Foley <mfo...@ohprs.org> writes:
>
> > Since you bring up that topic (Samba4 not recommended as a file server), I've been meaning to
> > ask on this list for a while: Why?
> > [...]
> >> As for the info you would like adding to the wiki, it used to be there,
> >> but when the wiki was re-written, it was removed. The thinking seemed to
> >> be, as samba doesn't recommend using the DC as a fileserver, it
> >> shouldn't be there. Samba has been recommending not using the DC as a
>
> What was said is "not using the DC as file server", not "not using
> Samba".
>
> My understanding is that it is better to have one machine running the DC
> and another serving files.
And it is a recommendation for a better layout,
not a strict requirement.
Reasons being that it is genrally better to separate
responsibilites, and that in this case, you have more
control over the fine-tunings of a file server if it
is not at the same time an AD/DC.
Cheers - Michael
Rowland penny
Jul 28, 2016, 4:20:03 AM7/28/16
to
On 28/07/16 07:43, Michael Adam wrote:
> Exactly. And it is a recommendation for a better layout, not a strict
> requirement. Reasons being that it is genrally better to separate
> responsibilites, and that in this case, you have more control over the
> fine-tunings of a file server if it is not at the same time an AD/DC.
> Cheers - Michael
>
This is all very well and good Michael, but what if you only have one
> Exactly. And it is a recommendation for a better layout, not a strict
> requirement. Reasons being that it is genrally better to separate
> responsibilites, and that in this case, you have more control over the
> fine-tunings of a file server if it is not at the same time an AD/DC.
> Cheers - Michael
>
computer ?
Microsoft recognised this and produced SBS, there are entire Linux
distro's being built around this idea (Clearos, SME), are they doing
wrong, or should the wiki now reflect this reality ?
What would help is if winbindd on the DC could be made to work more like
it does on a domain member i.e. allow setting of ranges
Rowland
Reindl Harald
Jul 28, 2016, 4:40:02 AM7/28/16
to
Am 28.07.2016 um 10:12 schrieb Rowland penny:
> On 28/07/16 07:43, Michael Adam wrote:
>> Exactly. And it is a recommendation for a better layout, not a strict
>> requirement. Reasons being that it is genrally better to separate
>> responsibilites, and that in this case, you have more control over the
>> fine-tunings of a file server if it is not at the same time an AD/DC.
>> Cheers - Michael
>
> This is all very well and good Michael, but what if you only have one
> computer?
every service
Reindl Harald
Jul 28, 2016, 4:40:02 AM7/28/16
to
Am 28.07.2016 um 07:31 schrieb Mark Foley:
> Since you bring up that topic (Samba4 not recommended as a file server), I've been meaning to
> ask on this list for a while: Why?
"not using the DC" != "not using samba4"
> -----Original Message-----
>> To: sa...@lists.samba.org
>> From: Rowland penny <rpe...@samba.org>
>> Date: Tue, 26 Jul 2016 22:13:43 +0100
>> Subject: Re: [Samba] sendmail getting domain\user as email userId
>>
Rowland penny
Jul 28, 2016, 4:40:03 AM7/28/16
to
Volker Lendecke
Jul 28, 2016, 4:50:03 AM7/28/16
to
On Thu, Jul 28, 2016 at 09:34:24AM +0100, Rowland penny wrote:
> On 28/07/16 09:29, Reindl Harald wrote:
> >
> >
> >Am 28.07.2016 um 10:12 schrieb Rowland penny:
> >>
> >>This is all very well and good Michael, but what if you only have one
> >>computer?
> >
> >then you setup a virtual machine which many people do in general for every
> >service
> >
> >
>
> But what if you don't want to setup a VM ?
You can of course export file shares from a DC. It's just that our file
> On 28/07/16 09:29, Reindl Harald wrote:
> >
> >
> >Am 28.07.2016 um 10:12 schrieb Rowland penny:
> >>
> >>This is all very well and good Michael, but what if you only have one
> >>computer?
> >
> >then you setup a virtual machine which many people do in general for every
> >service
> >
> >
>
> But what if you don't want to setup a VM ?
server has seen much wider deployment as an AD member instead of a DC,
that's all. There is much more experience with it, and all the topics
around idmapping are much better known. I'm not saying that they are
much better implemented, it's just the better-known setup.
Volker
Rowland penny
Jul 28, 2016, 5:00:03 AM7/28/16
to
On 28/07/16 09:43, Volker Lendecke wrote:
> You can of course export file shares from a DC. It's just that our
> file server has seen much wider deployment as an AD member instead of
> a DC, that's all. There is much more experience with it, and all the
> topics around idmapping are much better known. I'm not saying that
> they are much better implemented, it's just the better-known setup.
> Volker
Hi Volker, as far as I can see, the only problem is idmapping, only
> You can of course export file shares from a DC. It's just that our
> file server has seen much wider deployment as an AD member instead of
> a DC, that's all. There is much more experience with it, and all the
> topics around idmapping are much better known. I'm not saying that
> they are much better implemented, it's just the better-known setup.
> Volker
yesterday I found out that giving Domain Admins a gidNumber isn't a good
idea, the group needs to own Policies in sysvol.
Rowland
mathias dufresne
Jul 28, 2016, 5:30:02 AM7/28/16
to
mathias dufresne
Jul 28, 2016, 5:40:03 AM7/28/16
to
Can you explain why it would be an issue giving GID to "Domain Admins"
group?
group?
Rowland penny
Jul 28, 2016, 6:40:02 AM7/28/16
to
On 28/07/16 10:32, mathias dufresne wrote:
> Can you explain why it would be an issue giving GID to "Domain Admins"
> group?
>
This is because Domain Admins has to own group policies in sysvol, not
> Can you explain why it would be an issue giving GID to "Domain Admins"
> group?
>
as a group but as a user. If you give Domain Admins a gidNumber, it
becomes purely a group, so it cannot own the group policies as a user.
mathias dufresne
Jul 28, 2016, 7:00:03 AM7/28/16
to
2016-07-28 12:27 GMT+02:00 Rowland penny <rpe...@samba.org>:
> On 28/07/16 10:32, mathias dufresne wrote:
>
>> Can you explain why it would be an issue giving GID to "Domain Admins"
>> group?
>>
>>
> This is because Domain Admins has to own group policies in sysvol, not as
> a group but as a user. If you give Domain Admins a gidNumber, it becomes
> purely a group, so it cannot own the group policies as a user.
>
> This need sounds very strange to me... Why a group would need to be
> On 28/07/16 10:32, mathias dufresne wrote:
>
>> Can you explain why it would be an issue giving GID to "Domain Admins"
>> group?
>>
>>
> This is because Domain Admins has to own group policies in sysvol, not as
> a group but as a user. If you give Domain Admins a gidNumber, it becomes
> purely a group, so it cannot own the group policies as a user.
>
considered as a user?
I noticed earlier that groups are considered as users when it comes to
sysvol's ACLs. I thought it was because Samba was treating with XID rather
than UID and GID, and that use of XID is not precise enough to make
difference between users and groups, so to be sure Samba was putting ACL on
both sides (user ACL and group ACL). All that tought because Samba relies
on idmap and in idmap.ldb there is no UID/GID but only XID.
I don't think Windows clients are expecting to find groups in users' ACLs
so I'm really wondering why that would be an issue...
Rowland penny
Jul 28, 2016, 8:20:03 AM7/28/16
to
On 28/07/16 11:53, mathias dufresne wrote:
>
>
> 2016-07-28 12:27 GMT+02:00 Rowland penny <rpe...@samba.org
> <mailto:rpe...@samba.org>>:
>
>
> 2016-07-28 12:27 GMT+02:00 Rowland penny <rpe...@samba.org
>
> On 28/07/16 10:32, mathias dufresne wrote:
>
> Can you explain why it would be an issue giving GID to "Domain
> Admins" group?
>
>
> This is because Domain Admins has to own group policies in sysvol,
> not as a group but as a user. If you give Domain Admins a
> gidNumber, it becomes purely a group, so it cannot own the group
> policies as a user.
>
> This need sounds very strange to me... Why a group would need to be
> considered as a user?
>
> I noticed earlier that groups are considered as users when it comes to
> sysvol's ACLs. I thought it was because Samba was treating with XID
> rather than UID and GID, and that use of XID is not precise enough to
> make difference between users and groups, so to be sure Samba was
> putting ACL on both sides (user ACL and group ACL). All that tought
> because Samba relies on idmap and in idmap.ldb there is no UID/GID but
> only XID.
>
> I don't think Windows clients are expecting to find groups in users'
> ACLs so I'm really wondering why that would be an issue...
>
Yes it does sound strange, but, on windows, groups can and do own
> On 28/07/16 10:32, mathias dufresne wrote:
>
> Can you explain why it would be an issue giving GID to "Domain
> Admins" group?
>
>
> This is because Domain Admins has to own group policies in sysvol,
> not as a group but as a user. If you give Domain Admins a
> gidNumber, it becomes purely a group, so it cannot own the group
> policies as a user.
>
> This need sounds very strange to me... Why a group would need to be
> considered as a user?
>
> I noticed earlier that groups are considered as users when it comes to
> sysvol's ACLs. I thought it was because Samba was treating with XID
> rather than UID and GID, and that use of XID is not precise enough to
> make difference between users and groups, so to be sure Samba was
> putting ACL on both sides (user ACL and group ACL). All that tought
> because Samba relies on idmap and in idmap.ldb there is no UID/GID but
> only XID.
>
> I don't think Windows clients are expecting to find groups in users'
> ACLs so I'm really wondering why that would be an issue...
>
directories & files. An xidNumber is just that, a number, it is the
context in how that number is used that is important. If you give Domain
Admins a gidNumber attribute, then Domain Admins becomes just a group,
but if you examine Domain Admins object in idmap.ldb, you will find that
it is type 'ID_TYPE_BOTH'. This means that as far as Unix is concerned,
Domain Admins is both a user and a group, so it can own dirs & files.
Rowland
Jim Seymour
Jul 28, 2016, 9:10:03 AM7/28/16
to
On Thu, 28 Jul 2016 13:15:43 +0100
Rowland penny <rpe...@samba.org> wrote:
[snip]
[snip]
Hmmm...
----------------------------------------------------------------------
$ ldapsearch -x -ZZZ -b 'ou=Groups,dc=example,dc=com' 'cn=Domain Admins'
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=example,dc=com> with scope subtree
# filter: cn=Domain Admins
# requesting: ALL
#
# Domain Admins, Groups, example.com
dn: cn=Domain Admins,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: Domain Admins
gidNumber: 512
memberUid: root
description: Netbios Domain Administrators
sambaSID: S-1-5-21-3861070848-2803670205-3675378528-512
sambaGroupType: 2
displayName: Domain Admins
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
$ ldapmodify -x -ZZZ -W -D 'cn=admin,dc=example,dc=com'
Enter LDAP Password:
dn: cn=Domain Users,ou=Groups,dc=example,dc=com
changetype: modify
delete: gidNumber
modifying entry "cn=Domain Users,ou=Groups,dc=example,dc=com"
^D
ldap_modify: Object class violation (65)
additional info: object class 'posixGroup' requires attribute
'gidNumber'
----------------------------------------------------------------------
To me this implies that "posixGroup"s and an AD are incompatible?
(N.B.: I'm only posting this to satisfy my curiousity, not for any
practical reason.)
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
Rowland penny <rpe...@samba.org> wrote:
[snip]
>
> Yes it does sound strange, but, on windows, groups can and do own
> directories & files. An xidNumber is just that, a number, it is the
> context in how that number is used that is important. If you give
> Domain Admins a gidNumber attribute, then Domain Admins becomes just
> a group, ...
> Yes it does sound strange, but, on windows, groups can and do own
> directories & files. An xidNumber is just that, a number, it is the
> context in how that number is used that is important. If you give
> Domain Admins a gidNumber attribute, then Domain Admins becomes just
[snip]
Hmmm...
----------------------------------------------------------------------
$ ldapsearch -x -ZZZ -b 'ou=Groups,dc=example,dc=com' 'cn=Domain Admins'
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=example,dc=com> with scope subtree
# filter: cn=Domain Admins
# requesting: ALL
#
# Domain Admins, Groups, example.com
dn: cn=Domain Admins,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: Domain Admins
gidNumber: 512
memberUid: root
description: Netbios Domain Administrators
sambaSID: S-1-5-21-3861070848-2803670205-3675378528-512
sambaGroupType: 2
displayName: Domain Admins
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
$ ldapmodify -x -ZZZ -W -D 'cn=admin,dc=example,dc=com'
Enter LDAP Password:
dn: cn=Domain Users,ou=Groups,dc=example,dc=com
changetype: modify
delete: gidNumber
modifying entry "cn=Domain Users,ou=Groups,dc=example,dc=com"
^D
ldap_modify: Object class violation (65)
additional info: object class 'posixGroup' requires attribute
'gidNumber'
----------------------------------------------------------------------
To me this implies that "posixGroup"s and an AD are incompatible?
(N.B.: I'm only posting this to satisfy my curiousity, not for any
practical reason.)
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
Achim Gottinger
Jul 28, 2016, 9:30:03 AM7/28/16
to
What is the result of
getent passwd "Domain Admins"?
'getent group "Domain Admins"' should return the gid 512 but above may
return an value from idmap.ldb
achim~
Rowland penny
Jul 28, 2016, 9:40:03 AM7/28/16
to
ldap domain and in AD you don't need to explicitly set the posixGroup
objectClass.
Rowland
Data Control Systems - Mike Elkevizth
Jul 28, 2016, 11:20:02 AM7/28/16
to
Just to throw in my two cents, I too would love to see winbind on a DC
"act" the same as it does on a non-DC. I use my DCs as file servers, but
have had to use a number of workarounds because of how winbind acts
differently on a DC. I've not only had trouble with the idmappings, but
the fact that it doesn't honor all of the rfc2307 attributes. For
instance, I have a couple of users that use a file synchronization script
to keep files between the server and their laptops in sync. This script
requires them to logon to the file server (which is also a DC). Because
winbind on the DC doesn't honor my rfc2307 shell settings, I have to revert
to using the "template shell =" setting in smb.conf which means now that
all of my users can logon to the DC even if I don't want them to all have
access to that. I really don't understand why they don't act the same.?
Mike E.
"act" the same as it does on a non-DC. I use my DCs as file servers, but
have had to use a number of workarounds because of how winbind acts
differently on a DC. I've not only had trouble with the idmappings, but
the fact that it doesn't honor all of the rfc2307 attributes. For
instance, I have a couple of users that use a file synchronization script
to keep files between the server and their laptops in sync. This script
requires them to logon to the file server (which is also a DC). Because
winbind on the DC doesn't honor my rfc2307 shell settings, I have to revert
to using the "template shell =" setting in smb.conf which means now that
all of my users can logon to the DC even if I don't want them to all have
access to that. I really don't understand why they don't act the same.?
Mike E.
Rowland penny
Jul 28, 2016, 11:40:02 AM7/28/16
to
On 28/07/16 16:14, Data Control Systems - Mike Elkevizth wrote:
> Just to throw in my two cents, I too would love to see winbind on a DC
> "act" the same as it does on a non-DC. I use my DCs as file servers,
> but have had to use a number of workarounds because of how winbind
> acts differently on a DC. I've not only had trouble with the
> idmappings, but the fact that it doesn't honor all of the rfc2307
> attributes. For instance, I have a couple of users that use a file
> synchronization script to keep files between the server and their
> laptops in sync. This script requires them to logon to the file
> server (which is also a DC). Because winbind on the DC doesn't honor
> my rfc2307 shell settings, I have to revert to using the "template
> shell =" setting in smb.conf which means now that all of my users can
> logon to the DC even if I don't want them to all have access to that.
> I really don't understand why they don't act the same.?
>
>
There is a bug report about this:
> Just to throw in my two cents, I too would love to see winbind on a DC
> "act" the same as it does on a non-DC. I use my DCs as file servers,
> but have had to use a number of workarounds because of how winbind
> acts differently on a DC. I've not only had trouble with the
> idmappings, but the fact that it doesn't honor all of the rfc2307
> attributes. For instance, I have a couple of users that use a file
> synchronization script to keep files between the server and their
> laptops in sync. This script requires them to logon to the file
> server (which is also a DC). Because winbind on the DC doesn't honor
> my rfc2307 shell settings, I have to revert to using the "template
> shell =" setting in smb.conf which means now that all of my users can
> logon to the DC even if I don't want them to all have access to that.
> I really don't understand why they don't act the same.?
>
>
https://bugzilla.samba.org/show_bug.cgi?id=10886
Data Control Systems - Mike Elkevizth
Jul 28, 2016, 11:40:02 AM7/28/16
to
Hi Rowland,
Do you think it would help if more people commented on the bug? It hasn't
had any activity for over a year now. That's not very encouraging...
Mike E.
Do you think it would help if more people commented on the bug? It hasn't
had any activity for over a year now. That's not very encouraging...
Mike E.
Rowland penny
Jul 28, 2016, 11:50:02 AM7/28/16
to
On 28/07/16 16:37, Data Control Systems - Mike Elkevizth wrote:
> Hi Rowland,
>
> Do you think it would help if more people commented on the bug? It
> hasn't had any activity for over a year now. That's not very
> encouraging...
>
It wouldn't hurt, I am not sure that the rest of the Samba devs
> Hi Rowland,
>
> Do you think it would help if more people commented on the bug? It
> hasn't had any activity for over a year now. That's not very
> encouraging...
>
understand just how much this needs to be fixed.
Data Control Systems - Mike Elkevizth
Jul 28, 2016, 1:00:03 PM7/28/16
to
Well, there's one more comment for the bug. Probably wouldn't hurt if some
more people on this thread would add to it. 😀
Mike E.
more people on this thread would add to it. 😀
Mike E.
Mark Foley via samba
Aug 9, 2016, 10:40:03 PM8/9/16
to
Rowland - thanks for your comments in favor of AD/DC as file server.
I apologize for not being more specific in my initial post about stating that I was talking
about Samba4 as AD/DC, not just as a "classic" file server, although it appears that after the
first several comments list responders figured that out.
As I said in my initial post, I am not using the AD/DC as a traditional file server. I am using
it for a Maildir repository and for redirected folders. In the case of the latter, I did have
to configure smb.conf with the following:
[netlogon]
path = /var/lib/samba/sysvol/hprs.local/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[Users]
path = /redirectedFolders/Users
comment = user folders for redirection
read only = No
per Alexwyn's excellent instruction, "Folder Redirection using Group Policy - Samba 4 AD DC":
http://www.alexwyn.com/computer-tips/folder-redirection-samba4-active-directory-domain-controller
So, even though users don't do a specific "Map network drive" on their WIN7 workstations, this
config may technically be a samba share / file server.
As I said, I've been running this setup for about 2 years with zero problem.
--Mark
I apologize for not being more specific in my initial post about stating that I was talking
about Samba4 as AD/DC, not just as a "classic" file server, although it appears that after the
first several comments list responders figured that out.
As I said in my initial post, I am not using the AD/DC as a traditional file server. I am using
it for a Maildir repository and for redirected folders. In the case of the latter, I did have
to configure smb.conf with the following:
[netlogon]
path = /var/lib/samba/sysvol/hprs.local/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[Users]
path = /redirectedFolders/Users
comment = user folders for redirection
read only = No
per Alexwyn's excellent instruction, "Folder Redirection using Group Policy - Samba 4 AD DC":
http://www.alexwyn.com/computer-tips/folder-redirection-samba4-active-directory-domain-controller
So, even though users don't do a specific "Map network drive" on their WIN7 workstations, this
config may technically be a samba share / file server.
As I said, I've been running this setup for about 2 years with zero problem.
--Mark
Mark Foley via samba
Aug 9, 2016, 11:00:02 PM8/9/16
to
that is what this subject relates to). Doing this caused any file created by such users to be
created with the Administrator's UID of 3000000, not with their own UID. Rowland Penny figured
this out for me. See my final email on this in this list dated August 25, 2015 00:13 EDT, and,
generally, the thread subject "Samba4 DC/AD documents created in redirected folders with bogus
UID", in this maillist.
According to Rowland, van Belle and other contributors to that thread, this is normal Microsoft
behavoir and, as such, is probably appropriate for Samba4 if it has a goal of aping Microsoft's
AD, even if Microsoft's reasons for doing so are obscure. See this link provided by Rowland:
http://serverfault.com/questions/19311/file-ownership-for-new-files-with-administrator-why-is-it-giving-ownership-to
--Mark
0 new messages