Can't get Samba account provider work

The first attempt to join fails because smbd is not running at that moment. This should not be a problem, because we now try again after 5 seconds…

This seems the symptom of the real problem…

What was the error? Do you have any log excerpt with it?

BTW, reboot is not necessary!

Is 13 characters, that by adding the “nsdc-” prefix becomes 18 chars. This exceedes the 15 chars NetBIOS name limit. I don’t know if it is a problem but… /cc @quality_team

Could you try with a shorter hostname? I’d go with “planta2”. Under “Server name” page set as FQDN “planta2.kloncor.com.ar”, before installing the “Samba Account Provider” module. If you already installed it, remove it and apply the “Factory reset” procedure they suggested you some days ago.

Let’s see how it goes…

2 Likes

I played a litle bit with a vm.
When I use a short FQDN (ns7test.ns7.lan) after factory reset the DC, everything seems to work fine.

When I use a log FQDN (clonetestns7test.ns7.lan) I get this error:

After reboot:

and sssd service is stopped.
So I think you’re right with your suggestion with the FQDN @davidep
Is it possible to check in this field the maximum length of FQDN? Would avoid similar problems.

2 Likes

Those are great news! :smile: Thanks a lot @flatspin :thumbsup:

Please compare your log files with those above from @Auto_Bitacora and attach them here: could you confirm the error is the same?

Will try to reproduce tommorow. Crashed this machine.:blush: Don’t know how, but it’s gone. Luckily it was only a cloned vm :joy:

Good morning @davidep

this looks very similar, but not identical:

Sep 20 08:31:33 clonetestns7b2 systemd: Started Authorization Manager.
Sep 20 08:31:33 clonetestns7b2 realmd: * Resolving: _ldap._tcp.ns7.lan
Sep 20 08:31:33 clonetestns7b2 realmd: * Performing LDAP DSE lookup on: 192.168.0.239
Sep 20 08:31:33 clonetestns7b2 realmd: * Successfully discovered: ns7.lan
Sep 20 08:31:33 clonetestns7b2 realmd: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
Sep 20 08:31:33 clonetestns7b2 realmd: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.C05AOY -U Administrator ads join ns7.lan
Sep 20 08:31:33 clonetestns7b2 realmd: Enter Administrator’s password:gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: Server not found in Kerberos database]
Sep 20 08:31:33 clonetestns7b2 realmd: kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5) failed: An internal error occurred.
Sep 20 08:31:33 clonetestns7b2 realmd:
Sep 20 08:31:33 clonetestns7b2 realmd: Failed to join domain: failed to connect to AD: An internal error occurred.
Sep 20 08:31:33 clonetestns7b2 realmd: ! Joining the domain ns7.lan failed
Sep 20 08:31:33 clonetestns7b2 esmith::event[1768]: Password for Administrator: See: journalctl REALMD_OPERATION=r103.3526
Sep 20 08:31:33 clonetestns7b2 esmith::event[1768]: realm: Couldn’t join realm: Joining the domain ns7.lan failed
Sep 20 08:31:33 clonetestns7b2 esmith::event[1768]:
Sep 20 08:31:33 clonetestns7b2 esmith::event[1768]: [WARNING] DC join attempt 1 of 3 failed! Wait a few seconds…

In my case an internalt error occured, in his case the connection was refused.
No administrator is created during setup. But on network panel I get the “set password” message. :confused:

I can reproduce my error. Everytime when I take a long FQDN, I get an error.

Oh, I have to mention, that I have to delete the bridge manually after factory reset to get nsdc working again. Otherwise the bridge can’t be created during setup, and the vb-nsdc was not joined anymore to the bridge. So I had to do it manually. So best way is to delete the bridge in network panel before setup nsdc again.

Hope this helps.

Regards. Ralf.

3 Likes

They are the same!

This sounds strange because if a green bridge already exist it should be selected automatically…

Anyway thanks again @flatspin now I can open a bug!

More info from Red Hat:
https://bugzilla.redhat.com/show_bug.cgi?id=1001667

I want to highlight this link I found there:

The NetBIOS name is the OEM representation of the DNS host name up to MAX_COMPUTERNAME_LENGTH characters. If you set a DNS host name of more than MAX_COMPUTERNAME_LENGTH characters, the NetBIOS name is set to a truncated version of the DNS host name. Otherwise, the whole DNS host name is translated into the OEM NetBIOS name. Warning: If you modify the NetBIOS name so that it is not a truncated mapping of the DNS name, you will break applications that use functions such as DnsHostnameToComputerName which rely on this convention.

4 Likes

Hi @Auto_Bitacora, did you try it with a short FQDN? Did it work?

Thanks for reporting.

1 Like

Can someone point me at the Domain reset procedure. I have a system I need to change the Samba configuration on. Much thanks.

http://docs.nethserver.org/projects/nethserver-devel/en/v7b/nethserver-dc.html#factory-reset

:stuck_out_tongue_winking_eye:

2 Likes

Thank you!

I agree with you! Our FQDN module must check the length of the host name part. The NetBIOS limit of 15 chars seems acceptable for a host name.

This is my experiment:

NethServer FQDN: vm5verylongnamemorethan15.dpnet.nethesis.it
NethServer host name: vm5verylongnamemorethan15

When this server join the Samba AD domain a kerberos error occurs. I fixed that error… But still a problem:

Sep 20 17:50:47 vm5verylongnamemorethan15 realmd: * Resolving: _ldap._tcp.dpnet.nethesis.it
Sep 20 17:50:47 vm5verylongnamemorethan15 realmd: * Performing LDAP DSE lookup on: 192.168.122.55
Sep 20 17:50:47 vm5verylongnamemorethan15 realmd: * Successfully discovered: dpnet.nethesis.it
Sep 20 17:50:47 vm5verylongnamemorethan15 realmd: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
Sep 20 17:50:47 vm5verylongnamemorethan15 realmd: * Joining using a truncated netbios name: VM5VERYLONGNAME
Sep 20 17:50:47 vm5verylongnamemorethan15 realmd: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.N8NIOY -U Administrator ads join dpnet.nethesis.it
Sep 20 17:50:52 vm5verylongnamemorethan15 realmd: Enter Administrator's password:DNS update failed: NT_STATUS_INVALID_PARAMETER
Sep 20 17:50:52 vm5verylongnamemorethan15 realmd: 
Sep 20 17:50:52 vm5verylongnamemorethan15 realmd: Using short domain name -- DPNET
Sep 20 17:50:52 vm5verylongnamemorethan15 realmd: Joined 'VM5VERYLONGNAME' to dns domain 'dpnet.nethesis.it'
Sep 20 17:50:52 vm5verylongnamemorethan15 realmd: No DNS domain configured for vm5verylongname. Unable to perform DNS Update.

In AD LDAP the long host name appears truncated to 15 chars on every attribute:

name: VM5VERYLONGNAME
objectSid: S-1-5-21-2837209932-2259985391-103392534-1103
sAMAccountName: VM5VERYLONGNAME$
dNSHostName: vm5verylongname.dpnet.nethesis.it
servicePrincipalName: HOST/VM5VERYLONGNAME
servicePrincipalName: HOST/vm5verylongname.dpnet.nethesis.it
distinguishedName: CN=VM5VERYLONGNAME,CN=Computers,DC=dpnet,DC=nethesis,DC=it

This seems a good reason to limit the host name part to 15 chars.

Please comment,
/cc @dev_team @quality_team @support_team

2 Likes

I agree, 15 chars are acceptable, but the usable length for FQDN is only 10 chars, because in case of a AD setup the part “nsdc-” is added, or isn’t that affected?
Then maybe the “nsdc-” for the DC could be shortend to only “dc-”, so the usable FQDN-length for a DC would be 12 chars.

1 Like

You said it! The bugfix limit the nsdc name to 15 chars automatically. Have a look to my pull request on GitHub for details.

Even I don’t like Microsoft limitations, I agree with this: we must survive in a Windows scenario! :smiley:

3 Likes

We have the bug fix on nethserver-testing /cc @quality_team

On a clean machine

yum --enablerepo=nethserver-testing update nethserver-{base,sssd,dc} 

Please, see the test cases in the bug tracker!

https://github.com/NethServer/dev/issues/5110#issuecomment-248328526

4 Likes

I think you did it!!! It works!

I did a clean install. All updates and
I gave a long name (verylongnamens7test2.ns7.lan)
Installed directly from nethserver-testing the packages.
Started dc with green bridge.
And voila:

and

No errors in messages.log relating to sssd or nsdc.

Congratulations @davidep . :+1: :tada:

PS: I had to do yum install …otherwise nethserver-dc wouldn’t be installed on a clean machine.

4 Likes

Thank you @flatspin, could you remove the “testing” label and add the “verified” label to the GitHub issue?

1 Like

A post was split to a new topic: Controller provisioning fails with long domain name

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.