[Samba] NT_STATUS_INTERNAL_ERROR from RPC server on samba 4.5.8 AD DC
richard at connon.me.uk
Tue Oct 17 13:31:18 UTC 2017
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 ?
>>>>>> 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:
>>>> 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.
>> Try this smb.conf on the domain member:
>> 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
> 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.
More information about the samba