samba - Dec 2014 - Samba 4.1.14 Domain Controller as file server and internal winbind

Thanks,

Is there any site/blog/post/mail where I can find a more completed list
of issues/reasons?

Regards,
Bruno Andrade.

On 12/30/2014 12:59 PM, Rowland Penny wrote:
> On 30/12/14 12:27, Bruno Andrade wrote:
>> Hi,
>>
>> Im running a domain controller (AD DC) and file server, on the same
>> machine, with sernet-samba 4.1.14.
>>
>> Right now, I have a process using almost 100% CPU all the time. After
>> 'samba-tool processes' I found that the process is
winbind_server.
>>
>> On samba wiki page, they don't recommend using domain controller as
file
>> server because winbind issues.
>>
>> I already have other domain controller and file server, running without
>> problem.
>>
>> Why is not recommended using domain controller as file server?
>> What issues exists in winbind in this kind of environment?
>>
>> Regards,
>> Bruno Andrade.
>
> OK, winbind built into the samba daemon on the AD DC, is not the same
> as the separate winbind daemon you would use on a member server It
> does not have the same capabilities and is not setup in the same way,
> it cannot pull the Unix attributes from AD and these have to be set in
> smb.conf via templates. These templates mean that you cannot have
> different home directories based on the user. The UID & GID numbers on
> the AD DC are all in the 3000000 range, these numbers only exist on
> the DC, they will be different on any member server (and any other
DC's).
>
> There are other reasons why you should not use an AD DC as a
> fileserver, but the above reasons are the most obvious.
>
> Rowland

> >
> > OK, winbind built into the samba daemon on the AD DC, is not the same
> > as the separate winbind daemon you would use on a member server It
> > does not have the same capabilities and is not setup in the same way, 
(...)
> > There are other reasons why you should not use an AD DC as a
> > fileserver, but the above reasons are the most obvious.
> >

I thought you should know that the Release Notes for Samba 4.2 RC3 contain 
the following:


Winbindd use on the Samba AD DC
==============================
Winbindd is now used on the Samba AD DC by default, replacing the
partial rewrite used for winbind operations in Samba 4.0 and 4.1.

This allows more code to be shared, more options to be honoured, and
paves the way for support for trusted domains in the AD DC.

If required the old internal winbind can be activated by setting
'server services = +winbind -winbindd'.  Upgrading users with a server
services parameter specified should ensure they change 'winbind' to
'winbindd' to obtain the new functionality.

The 'samba' binary still manages the starting of this service, there
is no need to start the winbindd binary manually.


So hang on there, solution is on the way!

(I am using a AD DC and file server on the same machine without problems. 
It is serving serving a Windows only network, though.)

On 30/12/14 17:28, Miguel Medalha wrote:
>>> OK, winbind built into the samba daemon on the AD DC, is not the
same
>>> as the separate winbind daemon you would use on a member server It
>>> does not have the same capabilities and is not setup in the same
way,
> (...)
>
>>> There are other reasons why you should not use an AD DC as a
>>> fileserver, but the above reasons are the most obvious.
>>>
>
> I thought you should know that the Release Notes for Samba 4.2 RC3 contain
> the following:
>
>
> Winbindd use on the Samba AD DC
> ==============================>
> Winbindd is now used on the Samba AD DC by default, replacing the
> partial rewrite used for winbind operations in Samba 4.0 and 4.1.
>
> This allows more code to be shared, more options to be honoured, and
> paves the way for support for trusted domains in the AD DC.
>
> If required the old internal winbind can be activated by setting
> 'server services = +winbind -winbindd'.  Upgrading users with a
server
> services parameter specified should ensure they change 'winbind' to
> 'winbindd' to obtain the new functionality.
>
> The 'samba' binary still manages the starting of this service,
there
> is no need to start the winbindd binary manually.
>
>
> So hang on there, solution is on the way!
Sorry, but no, as far as the Unix attributes etc are concerned, there is 
no change, you still have to use the templates. I know that this is far 
from ideal, but the main idea behind integrating the separate winbind 
daemon was to get trusts working correctly. We will just have to wait 
patiently until the devs get the time to sort out the Unix attributes, 
hopefully this will be sooner rather than later, but as I said, we will 
have to wait.

Rowland
>
> (I am using a AD DC and file server on the same machine without problems.
> It is serving serving a Windows only network, though.)