samba - Oct 2017 - NT_STATUS_INTERNAL_ERROR from RPC server on samba 4.5.8 AD DC

On Tue, 17 Oct 2017 13:18:46 +0100
Richard Connon via samba <samba at lists.samba.org> wrote:
> 
> 
> On 17/10/2017 09:54, Rowland Penny via samba wrote:
> > On Tue, 17 Oct 2017 09:29:00 +0100
> > Richard Connon via samba <samba at lists.samba.org> wrote:
> >
> >> On 16/10/2017 19:30, Rowland Penny wrote:
> >>> Is the member server using DHCP ?
> >> Yes. Both test hosts are using DHCP with static leases for IP
> >> addresses but not for DNS domains or nameservers.
> > I wouldn't do this, I would give the DC a fixed ipaddress.
> In my production environment my DC(s) have fixed IP addresses, the
> use of DHCP is only in my lab environment. Do you see a problem with
> doing this as long as the IPs don't change during testing? (they are
> static leases)
> >>> Is '10.0.2.15' the ipaddress of the DC ?
> >> Yes
> >>> You haven't got 'security = ADS' in your smb.conf.
> >> Assuming you mean on the member, good point, but it doesn't
change
> >> this behaviour. My understanding was this only affected smbd
> >> anyway, which I'm not running on the member.
> > You need it
> OK. I've set it now and see no change in behaviour.
> >>> You have 'unix password sync = yes' in smb.conf,
> >>> Do you have Unix users that are also in AD ?
> >> No, this is just a default smb.conf from debian. I assume this
> >> wouldn't actually have any affect on a member server where
there is
> >> no local passdb anyway and again, removing it has no affect.
> > It wouldn't help.
> I've removed this now and see no change in behaviour.
> > And finally the biggy, are you using sssd ?
> >> No, these test hosts are very basic debian installs I've done
to
> >> attempt to isolate this problem, although my
"production" installs
> >> use SSSD.
> > Then it is never going to work, you have not set up winbind at all.
> >
> > Can I suggest you go and read this:
> >
> > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
> >
> > I suggest you follow it and use the 'rid' backend.
> Again, this is a production/lab difference. I didn't setup SSSD in
> the lab to reduce the complexity. I'm simply trying to get the actual
> join process working. I will follow through that wiki anyway to check
> there's nothing I've missed though.
> > Rowland
> >
Try this smb.conf on the domain member:

[global]
    workgroup = TEST
    security = ADS
    realm = ADS.TEST.LOCAL

    winbind use default domain = yes
    winbind expand groups = 4
    winbind refresh tickets = Yes
    winbind offline logon = yes

    idmap config *:backend = tdb
    idmap config *:range = 2000-9999
    idmap config TEST : backend = rid
    idmap config TEST : range = 10000-999999
    template shell = /bin/bash
    template homedir = /home/%U

    domain master = no
    local master = no
    preferred master = no
    os level = 20
    map to guest = bad user
    host msdfs = no

    vfs objects = acl_xattr
    map acl inherit = Yes
    store dos attributes = Yes

If 'net ads join -U Administrator' doesn't work, then you need to
look
elsewhere, is a firewall in the way, is Apparmor running and getting in
the way 

Rowland

On 17/10/2017 13:56, Rowland Penny via samba wrote:
> On Tue, 17 Oct 2017 13:18:46 +0100
> Richard Connon via samba <samba at lists.samba.org> wrote:
>
>>
>> On 17/10/2017 09:54, Rowland Penny via samba wrote:
>>> On Tue, 17 Oct 2017 09:29:00 +0100
>>> Richard Connon via samba <samba at lists.samba.org> wrote:
>>>
>>>> On 16/10/2017 19:30, Rowland Penny wrote:
>>>>> Is the member server using DHCP ?
>>>> Yes. Both test hosts are using DHCP with static leases for IP
>>>> addresses but not for DNS domains or nameservers.
>>> I wouldn't do this, I would give the DC a fixed ipaddress.
>> In my production environment my DC(s) have fixed IP addresses, the
>> use of DHCP is only in my lab environment. Do you see a problem with
>> doing this as long as the IPs don't change during testing? (they
are
>> static leases)
>>>>> Is '10.0.2.15' the ipaddress of the DC ?
>>>> Yes
>>>>> You haven't got 'security = ADS' in your
smb.conf.
>>>> Assuming you mean on the member, good point, but it doesn't
change
>>>> this behaviour. My understanding was this only affected smbd
>>>> anyway, which I'm not running on the member.
>>> You need it
>> OK. I've set it now and see no change in behaviour.
>>>>> You have 'unix password sync = yes' in smb.conf,
>>>>> Do you have Unix users that are also in AD ?
>>>> No, this is just a default smb.conf from debian. I assume this
>>>> wouldn't actually have any affect on a member server where
there is
>>>> no local passdb anyway and again, removing it has no affect.
>>> It wouldn't help.
>> I've removed this now and see no change in behaviour.
>>> And finally the biggy, are you using sssd ?
>>>> No, these test hosts are very basic debian installs I've
done to
>>>> attempt to isolate this problem, although my
"production" installs
>>>> use SSSD.
>>> Then it is never going to work, you have not set up winbind at all.
>>>
>>> Can I suggest you go and read this:
>>>
>>>
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
>>>
>>> I suggest you follow it and use the 'rid' backend.
>> Again, this is a production/lab difference. I didn't setup SSSD in
>> the lab to reduce the complexity. I'm simply trying to get the
actual
>> join process working. I will follow through that wiki anyway to check
>> there's nothing I've missed though.
>>> Rowland
>>>
> Try this smb.conf on the domain member:
>
> [global]
>      workgroup = TEST
>      security = ADS
>      realm = ADS.TEST.LOCAL
>
>      winbind use default domain = yes
>      winbind expand groups = 4
>      winbind refresh tickets = Yes
>      winbind offline logon = yes
>
>      idmap config *:backend = tdb
>      idmap config *:range = 2000-9999
>      idmap config TEST : backend = rid
>      idmap config TEST : range = 10000-999999
>      template shell = /bin/bash
>      template homedir = /home/%U
>
>      domain master = no
>      local master = no
>      preferred master = no
>      os level = 20
>      map to guest = bad user
>      host msdfs = no
>
>      vfs objects = acl_xattr
>      map acl inherit = Yes
>      store dos attributes = Yes
>
> If 'net ads join -U Administrator' doesn't work, then you need
to look
> elsewhere, is a firewall in the way, is Apparmor running and getting in
> the way
>
> Rowland
>
>
I tried this template and the behaviour still doesn't change. There is 
no firewall between the hosts, they are in the same subnet. Apparmor is 
not running on either host.

Earlier I tried to isolate the problem by just connecting to the RPC 
server using rpcclient. Should this work correctly?

On 17/10/2017 14:08, Richard Connon via samba wrote:
> On 17/10/2017 13:56, Rowland Penny via samba wrote:
>
>> On Tue, 17 Oct 2017 13:18:46 +0100
>> Richard Connon via samba <samba at lists.samba.org> wrote:
>>
>>>
>>> On 17/10/2017 09:54, Rowland Penny via samba wrote:
>>>> On Tue, 17 Oct 2017 09:29:00 +0100
>>>> Richard Connon via samba <samba at lists.samba.org>
wrote:
>>>>
>>>>> On 16/10/2017 19:30, Rowland Penny wrote:
>>>>>> Is the member server using DHCP ?
>>>>> Yes. Both test hosts are using DHCP with static leases for
IP
>>>>> addresses but not for DNS domains or nameservers.
>>>> I wouldn't do this, I would give the DC a fixed ipaddress.
>>> In my production environment my DC(s) have fixed IP addresses, the
>>> use of DHCP is only in my lab environment. Do you see a problem
with
>>> doing this as long as the IPs don't change during testing?
(they are
>>> static leases)
>>>>>> Is '10.0.2.15' the ipaddress of the DC ?
>>>>> Yes
>>>>>> You haven't got 'security = ADS' in your
smb.conf.
>>>>> Assuming you mean on the member, good point, but it
doesn't change
>>>>> this behaviour. My understanding was this only affected
smbd
>>>>> anyway, which I'm not running on the member.
>>>> You need it
>>> OK. I've set it now and see no change in behaviour.
>>>>>> You have 'unix password sync = yes' in
smb.conf,
>>>>>> Do you have Unix users that are also in AD ?
>>>>> No, this is just a default smb.conf from debian. I assume
this
>>>>> wouldn't actually have any affect on a member server
where there is
>>>>> no local passdb anyway and again, removing it has no
affect.
>>>> It wouldn't help.
>>> I've removed this now and see no change in behaviour.
>>>> And finally the biggy, are you using sssd ?
>>>>> No, these test hosts are very basic debian installs
I've done to
>>>>> attempt to isolate this problem, although my
"production" installs
>>>>> use SSSD.
>>>> Then it is never going to work, you have not set up winbind at
all.
>>>>
>>>> Can I suggest you go and read this:
>>>>
>>>>
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
>>>>
>>>> I suggest you follow it and use the 'rid' backend.
>>> Again, this is a production/lab difference. I didn't setup SSSD
in
>>> the lab to reduce the complexity. I'm simply trying to get the
actual
>>> join process working. I will follow through that wiki anyway to
check
>>> there's nothing I've missed though.
>>>> Rowland
>>>>
>> Try this smb.conf on the domain member:
>>
>> [global]
>>      workgroup = TEST
>>      security = ADS
>>      realm = ADS.TEST.LOCAL
>>
>>      winbind use default domain = yes
>>      winbind expand groups = 4
>>      winbind refresh tickets = Yes
>>      winbind offline logon = yes
>>
>>      idmap config *:backend = tdb
>>      idmap config *:range = 2000-9999
>>      idmap config TEST : backend = rid
>>      idmap config TEST : range = 10000-999999
>>      template shell = /bin/bash
>>      template homedir = /home/%U
>>
>>      domain master = no
>>      local master = no
>>      preferred master = no
>>      os level = 20
>>      map to guest = bad user
>>      host msdfs = no
>>
>>      vfs objects = acl_xattr
>>      map acl inherit = Yes
>>      store dos attributes = Yes
>>
>> If 'net ads join -U Administrator' doesn't work, then you
need to look
>> elsewhere, is a firewall in the way, is Apparmor running and getting in
>> the way
>>
>> Rowland
>>
>>
> I tried this template and the behaviour still doesn't change. There is 
> no firewall between the hosts, they are in the same subnet. Apparmor 
> is not running on either host.
>
> Earlier I tried to isolate the problem by just connecting to the RPC 
> server using rpcclient. Should this work correctly
Well I just stumbled on my problem almost by accident. On my test 
environment the "winbind" package was not installed and in my
production
environment, additionally, I still had "winbind" not
"winbindd" in my
smb.conf for the DC.