[Samba] NT_STATUS_INTERNAL_ERROR from RPC server on samba 4.5.8 AD DC

[Rowland Penny]

On Tue, 17 Oct 2017 14:31:18 +0100
Richard Connon via samba <samba at lists.samba.org> wrote:

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

I said that you didn't have winbind installed, didn't this give you a
hint ?
It also doesn't matter if you have 'winbind' or 'winbindd' in the
'server services' line in the DC smb.conf, one is a symlink to the
other.

Rowland