Error enable ActiveDirectory

Brief description of the problem

Enabling the Active Directory service gives an error.

Detailed step by step instructions to reproduce the problem

connection in the terminal through the realm with the same credentials goes fine
but there I indicate the domain name and not the domain controller
If I specify a domain in WEB-UI, it cannot be resolved. the terminal resolves the domain correctly

Web-UI screenshot

[


]
Снимок экрана от 2024-07-16 12-40-08

Error Traceback provided on the Web-UI

Traceback (most recent call last): File "/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py", line 41, in _handle_exception yield File "/opt/rockstor/src/rockstor/smart_manager/views/active_directory.py", line 163, in post config["workgroup"] = domain_workgroup(domain, method=method) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/rockstor/src/rockstor/system/directory_services.py", line 311, in domain_workgroup o, e, rc = run_command(cmd, log=True) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/rockstor/src/rockstor/system/osi.py", line 290, in run_command raise CommandException(cmd, out, err, rc) system.exceptions.CommandException: Error running a command. cmd = /usr/bin/net ads workgroup --realm=SRVDC0.DOM.LOCAL. rc = 255. stdout = ['']. stderr = ['ads_connect: No logon servers are currently available to service the logon request.', "Didn't find the cldap server!", '']

@grif thanks for the error report. Could you let us know which version of Rockstor you are using?

The only thing I noticed it that there seems to be an additional . at the end of the realm, but not sure whether that’s just the way the traceback reports it out:

I assume, if you try to ping the server from Rockstor’s command line that you get a response?
Have you tried to join the domain from the command line to see whether this is an issue within Rockstor or a general problem (e.g. lack of connectivity, missing packages though that should not be the root cause, etc.).

2 Likes

System is running Rockstor version: 5.0.12-0
Uses openSUSE Leap: 1
Linux: 6.4.0-150600.23.7-default

/usr/bin/net ads workgroup --realm=SRVDC0.DOM.LOCAL.
ads_connect: No logon servers are currently available to service the logon request.
Didn’t find the cldap server!

net ads lookup -S 10.55.2.2
Information for Domain Controller: 10.55.2.2

Response Type: LOGON_SAM_LOGON_RESPONSE_EX
GUID:
Flags:
Is a PDC: yes
Is a GC of the forest: yes
Is an LDAP server: yes
Supports DS: yes
Is running a KDC: yes
Is running time services: yes
Is the closest DC: yes
Is writable: yes
Has a hardware clock: no
Is a non-domain NC serviced by LDAP server: no
Is NT6 DC that has some secrets: no
Is NT6 DC that has all secrets: yes
Runs Active Directory Web Services: yes
Runs on Windows 2012 or later: yes
Runs on Windows 2012R2 or later: yes
Runs on Windows 2016 or later: yes
Has a DNS name: no
Is a default NC: no
Is the forest root: no
Forest: DOM.LOCAL.
Domain: DOM.LOCAL.
Domain Controller: SRVDC0.DOM.LOCAL.
Pre-Win2k Domain: DOM
Pre-Win2k Hostname: SRVDC0
Server Site Name: ЦО
Client Site Name: ЦО
NT Version: 5
LMNT Token: ffff
LM20 Token: ffff

nslookup SRVDC0.DOM.LOCAL.
Server: 10.55.2.2
Address: 10.55.2.2#53

Name: SRVDC0.DOM.LOCAL.
Address: 10.55.2.2

nslookup dom.local
Server: 10.55.2.2
Address: 10.55.2.2#53

Name: dom.local
Address: 10.55.2.2
Name: dom.local
Address: 172.16.200.17
Name: dom.local
Address: 10.5.0.3
Name: dom.local
Address: 10.5.24.5
Name: dom.local
Address: 10.5.8.1

realm discover -v dom.local

  • Resolving: _ldap._tcp.dom.local
  • Performing LDAP DSE lookup on: 10.5.0.3
  • Performing LDAP DSE lookup on: 172.16.200.17
  • Performing LDAP DSE lookup on: 10.5.8.1
  • Successfully discovered: dom.local
    dom.local
    type: kerberos
    realm-name: DOM.LOCAL.
    domain-name: dom.local
    configured: no
    server-software: active-directory
    client-software: sssd
    required-package: sssd-tools
    required-package: sssd
    required-package: adcli
    required-package: samba-client

realm join -v -U grif dom.local

  • Resolving: _ldap._tcp.dom.local
  • Performing LDAP DSE lookup on: 10.5.8.1
  • Performing LDAP DSE lookup on: 10.5.24.5
  • Performing LDAP DSE lookup on: 10.5.0.3
  • Successfully discovered: dom.local
    Password for grif:
  • Required files: /usr/sbin/sss_cache, /usr/sbin/sssd, /usr/sbin/adcli
  • LANG=C /usr/sbin/adcli join --verbose --domain dom.local --domain-realm DOM.LOCAL --domain-controller 10.5.24.5 --login-type user --login-user grif --stdin-password
  • Using domain name: dom.local
  • Calculated computer account name from fqdn: DS-04
  • Using domain realm: dom.local
  • Sending netlogon pings to domain controller: cldap://10.5.24.5
  • Received NetLogon info from: vsw-g58-dc.dom.local
  • Wrote out krb5.conf snippet to /tmp/adcli-krb5-RXt6o7/krb5.d/adcli-krb5-conf-4ndVpA
  • Authenticated as user: grif@DOM.LOCAL
  • Using GSS-SPNEGO for SASL bind
  • Looked up short domain name: DOM
  • Looked up domain SID:
  • Using fully qualified name: ds-04.dom.local
  • Using domain name: dom.local
  • Using computer account name: DS-04
  • Using domain realm: dom.local
  • Calculated computer account name from fqdn: DS-04
  • Generated 120 character computer password
  • Using keytab: FILE:/etc/krb5.keytab
  • Found computer account for DS-04$ at: CN=DS-04,CN=Computers,DC=dom,DC=local
  • Sending netlogon pings to domain controller: cldap://10.5.24.5
  • Received NetLogon info from: vsw-g58-dc.dom.local
  • Set computer password
  • Retrieved kvno ‘3’ for computer account in directory: CN=DS-04,CN=Computers,DC=dom,DC=local
  • Discovered which keytab salt to use
  • Added the entries to the keytab: DS-04$@DOM.LOCAL: FILE:/etc/krb5.keytab
  • Added the entries to the keytab: host/DS-04@DOM.LOCAL: FILE:/etc/krb5.keytab
  • Added the entries to the keytab: host/ds-04.dom.local@DOM.LOCAL: FILE:/etc/krb5.keytab
  • Added the entries to the keytab: RestrictedKrbHost/DS-04@DOM.LOCAL: FILE:/etc/krb5.keytab
  • Added the entries to the keytab: RestrictedKrbHost/ds-04.dom.local@DOM.LOCAL: FILE:/etc/krb5.keytab
  • /usr/bin/systemctl enable sssd.service
    Created symlink /etc/systemd/system/multi-user.target.wants/sssd.service → /usr/lib/systemd/system/sssd.service.
  • /usr/bin/systemctl restart sssd.service
  • /bin/sh -c /usr/sbin/pam-config --add --sss --mkhomedir && sed -E ‘s/(passwd:.) sss/\1/; s/(passwd:.)/\1 sss/; s/(group:.) sss/\1/; s/(group:.)/\1 sss/; s/(shadow:.) sss/\1/; s/(shadow:.)/\1 sss/;’ -i /etc/nsswitch.conf
  • Successfully enrolled machine in realm

realm list
dom.local
type: kerberos
realm-name: DOM.LOCAL
domain-name: dom.local
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: adcli
required-package: samba-client
login-formats: %U@dom.local
login-policy: allow-realm-logins

but Active Directory service not started in WEB-UI

Hi @grif,

Nice to see you all up-to-date now :slight_smile:

I unfortunately do not have access to my local AD test setup to verify this myself (currently moving) so I’ll try to help as much as possible without that. Fortunately, you provided a lot of information so it gives us a good idea, I think.

I believe yourself and @Hooverdan are both correct and on the right track In particular, I’m thinking about:

… alongside

My first thought is an issue with the domain name entered in the webUI. Indeed, based on what you described (quoted above) and the realm input, it seems you may try to enter the domain name directly and not the domain controller (that’s if I understand your AD setup correctly).

The above tends to support that so I would try that first. I’m not sure where you left you system at given you have tried (and joined) using the cli so you may need to leave the AD (realm leave <domain-name>) and even clear SSSD’s cache. That’s if you want Rockstor to take care of that, of course.

As a side note, I thought I would detail a bit more the process used by Rockstor to join an AD in case it helps your troubleshooting.

First, we make sure that time synchronization is set up:

Then, we make sure the Rockstor machine can see the AD domain.

Then, we fetch the WORKGROUP currently setup on the AD server to ensure that Samba running on the Rockstor machine is set using the same (and we set it up if needed).

This is the step that is failing for you so let’s look at it: in short, we’re using net to fetch just that:

Hopefully this helps move things along at least a bit further.

2 Likes

I don’t understand how these commands can be executed from the terminal

@grif Hello there, just chipping on on:

The code snippets @Flox references are to help understand how Rockstor works: we rely on folks reports and feedback to help us help them get to what has gone wrong, or in this case a suspected miss-entry/miss-config during the AD setup. You can also then see the other elements that we tie together to configure AD.

This is the key bit in @Flox response:

I.e. as you have already now done some CLI based configuration, it may conflict with what the Web-UI entered config may try to apply, or re-apply if you reconfigur it according to @Flox & @Hooverdan suspicion after looking at your feedback. So they have suggested you do a realm leave command and clear the sssd cache (sorry I don’t know this area well) then try to re-do your Web-UI AD config according to the advice.

Hope that helps.

1 Like

I made realm leave and clear sss_cache
ntp and samba services “on”

/usr/bin/net ads workgroup --realm=SRVDC0.DOM.LOCAL.
ads_connect: No logon servers are currently available to service the logon request.
Didn’t find the cldap server!

/usr/bin/net ads workgroup --realm=dom.local.
Workgroup: DOM

but I still have the same error as the first message

Thanks for checking these, @grif , it seems to confirm you need to enter the second one as the “Domain / Realm name” in the Web UI configuration. Following your example, it would be dom.local

Снимок экрана от 2024-07-19 08-18-57

Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/smart_manager/views/active_directory.py”, line 58, in _resolve_check
socket.gethostbyname(domain)
socket.gaierror: [Errno -2] Name or service not known

written to /etc/hosts
10.55.2.2 dom.local
this helped to enable the active directory service

but it’s still not clear why nslookup dom.local from the terminal is resolved normally, but from the WEB-UI it doesn’t pass the test

When accessing the list of users, the following message appears
Снимок экрана от 2024-07-19 18-29-25

@grif Re:

This is an unrelated Web-UI bug due to some older libs we still use there. Just refresh the page using the browser, and this goes away. It has no other bearing. We are due to begin refreshing/updating our Web-UI libs/technologies in the next testing phase.

Hope that helps.

2 Likes

When I try to enable a domain group on a share, it gives an incomprehensible error

correction, any change of group or user results in this error. owner root:root

these shares were created in the old rockstor system. and were not disabled correctly.
how can I fix this?

created a test pool on a flash drive. domain group rights were assigned to him without errors.
Tell me how to fix the old shares so that they can accept the rights of the new domain