Active Directory Integration failure

[computergeek125]

Currently, I am trying out Rockstor in a VM on ESXi. I have not done a whole lot of configuration on it due to lack of time, and I want to get the AD sorted before I get too deep into this system.

I’ve gotten about as far as:

• Install rockstor from ISO (Rockstor-3.9.1.iso), which I think is the correct version (checksummed at the NAS it lives on, ESXi reads directly from NFS)
• Turn on automatic updates and run a manual update
  • Manually reboot because it usually bugs the automatic reboot at this point
• Make rockon share (lzo compression enabled)
• turn on rockons
• Set AD settings (RFC2307 enabled)
• Attempt to turn on AD service

…Which greets me with this error message:

            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 199, in post
    smb_config = self._get_config(smbo)
  File "/opt/rockstor/src/rockstor/smart_manager/views/base_service.py", line 40, in _get_config
    return json.loads(service.config)
  File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
    return _default_decoder.decode(s)
  File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: expected string or buffer

I found the wiki page that said how the architecture was based on SSSD, which I’m somewhat familiar with, so I hopped on SSH to see if I could find out anything directly from realmd:

[root@nas-taliyah ~]# realm join -v -U admin win.example.com
 * Resolving: _ldap._tcp.win.example.com
 * Performing LDAP DSE lookup on: x.x.x.x
 * Successfully discovered: win.example.com
Password for admin: ********
 * Couldn't find file: /usr/sbin/sssd
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
 * Resolving required packages
 ! PackageKit not available: The name org.freedesktop.PackageKit was not provided by any .service files
 ! Necessary packages are not installed: oddjob, oddjob-mkhomedir, sssd, samba-common-tools
realm: Couldn't join realm: Necessary packages are not installed: oddjob, oddjob-mkhomedir, sssd, samba-common-tools
[root@nas-taliyah ~]# 

Now, I could install all those packages (and I usually do when I’m configuring this on my own), but I would expect that a base install has the requisite dependencies already loaded by the time I can get to a UI screen that can trigger a realm join.

Did I miss a “install required dependencies” button? For my homelab, AD/Kerberos is pretty much required since desktops and laptops have GPO drive mappings.

Further testing:

I took a snapshot of the VM and installed PackageKit, but the GUI is still not able to join the domain. Joining by hand, realmd is able to use PackageKit to install the necessary dependencies and the join succeeds. At this point, the GUI does not reflect changes (not that I’d expect it to), but from the CLI, i can su to an AD user with a password (root does allow the automatic su, so I went to my local admin account then an AD user).

Un-joining the domain via CLI then trying to re-join using the GUI fails with the original error.

Joining the domain via CLI then trying to turn on the Active Directory service also yields this error.

[Flox]

Hi @computergeek125, and welcome!

Thank you for your detailed, structured, and clear report… even though I’m not familiar with AD and its config, I do see something that may explain what you’re experiencing:

   smb_config = self._get_config(smbo)
(...)
   return json.loads(service.config)
(...)
   return _default_decoder.decode(s)
(...)
TypeError: expected string or buffer

Here, we can see that before starting the AD service, it is trying to load the samba service config but fails as the latter seems empty. As you didn’t describe configuring and starting the samba service in your reproducer steps, I’m wondering if that could “simply” be the problem.

Hopefully this helps, and I’m sure users more knowledgeable in the AD system will answer!

[phillxnet (Philip Guyton)]

@computergeek125 Thanks for sharing your findings here.

First: what @Flox said.

I’d like just to note that with regard to:

I found the wiki page that said how the architecture was based on SSSD …

I’m afraid that those docs are a little dated. I haven’t worked much in that area myself so haven’t gotten around to ‘fixing’ them but the story is that for a time we switched whole sale to sssd and I was all in favour of using this newer system. But there was a backlash as many windows domain controller managed domains failed, so our sssd changes were essentially reverted to appease those clients. I’m personally in favour of going all in on sssd again post our openSUSE move as we would then have access to the much newer versions of the sssd stuff. That was what bite us back last time, sssd just wasn’t ready or well enough know at the time to be effectively used / understood by our existing clients. But I was not project lead at the time and the decision had merit in that it returned ‘know function’.

So apologies for your garden path doc discoveries but post a switch back and we would again be in keeping with those docs. But as we are community lead project and we just haven’t had anyone step up to this task, and the core developers are otherwise quite busy preparing the openSUSE move which in turn will help with such things as getting newer sssd which can only help.

So in short I’d like to ideally use only sssd but a more pragmatic approach would be to have a selector, but given the selector approach would entail a great deal more complexity, in the light of the number of folks who have stepped up to maintain this code (far less than a hand full) I’m currently favouring a hard return to our sssd only code and work stuff out from there.

A good place to start for anyone wanting to see this code in a better state would be to look at it’s history within rockstor-core and keep in mind it integration with our samba config. I’m actually not that up on AD stuff and only knew a little of the sssd approach and was chuffed when we moved over to that, but it was very short lived due to the bad reaction to loss of functionality. This, as stated, was I believe down to the young nature of sssd at the time.

Given you have obvious knowledge of this ‘domain’ yourself do feel free to take a look at the code and see what we might be doing wrong, but I think you may currently have both systems in place and they are not playing nicely with each other.

Apologies I can’t spend much more time on this as I see our openSUSE move as underpinning all other elements as so this has to take precedence currently.

Hope that helps.

[phillxnet (Philip Guyton)]

@computergeek125 & @Flox Re:

@phillxnet

But there was a backlash as many windows domain controller managed domains failed, so our sssd changes were essentially reverted to appease those clients. I’m personally in favour of going all in on sssd again post our openSUSE move as we would then have access to the much newer versions of the sssd stuff.

Just looked up the release announcement where we reverted the sssd approach:

Dev log for upcoming 3.8-12 [Latest: 3.8-11.18]

3.8-11.15 is now available! This is a special one where we fixed two issues that have been painful to many users. AD integration has been broken in a few different ways with our sssd approach. It looks great in theory and I am open to bringing it back again, but many users ran into issues including Rockstor dropping off the domain, id mapping issues and windows ACLs. So, we are bringing back the winbind approach. We’ve tested it quite a bit and encourage everyone to do the same. It has bee…

So that dates the change and would be a good place to see what was reverted. Again, I’m all in favour of the sssd approach and would love to bring it back, if at all viable.

Hope this encourages those interested to take a look at this area of the code as it’s definitely an area that could do with some attention from those in the know.

If you are otherwise only interested in ‘getting up and running’ then your would be best advised to wipe all sssd stuff and go with the current ‘flow’ of our dated but apparently working for some winbind approach. But I will be favouring any work that moves us back to sssd; from the research I did at the time it looked, to me at least, like the way to go. And again, offering both with our current core developer count, and the low community code engagement in this area, is just not going to fly.

Again I hope this helps those wishing to see this side of Rockstor shape/new up a tad.

[phillxnet (Philip Guyton)]

@computergeek125 and @Flox

Just to help complete the info here, re:

quote=“phillxnet, post:4, topic:6681”]
So that dates the change and would be a good place to see what was reverted.
[/quote]

earlier in that same forum thread we see the prior attempt to maintain the sssd approach. Both me and Suman were in favour but it just didn’t work out, at the time.

Dev log for upcoming 3.8-12 [Latest: 3.8-11.18]

It’s been a bit slower development pace last few days, I spent way too much time than I wished on fixing up AD integration issues. Thanks to users for reporting issues and @JBelthoff especially for providing deeper insights into a winbind based setup. Some of you are aware, I am sure, that Rockstor uses the newer SSS based approach summarized here. I almost gave in and went back to winbind, but I was able to fill in some gaps and everything seems to be working in my environment with 2012 R2 AD s…

So I’m hoping someone with sufficient domain knowledge is willing to move us back to the sssd approach as per Suman’s original approach and that the underlying systems will then work better for us. As stated I’d rather use this ‘revamped’ approach than the older windbind based stuff.

Apologies for potentially bombarding this thread.

Also relevant to your trials is the very old version of Rockstor you look to be using. Our latest released code are now available via the Stable channel on the CentOS front, our via source install, or via the testing channel on the openSUSE front, detailed in the following thread:

Built on openSUSE testing channel live (early-adopters/developers only)

As per more recent changes to our Update Channels docs and following our ongoing developer doc: We now have very early testing channel rpms available for openSUSE Leap15.1 / Leap15.2, and Tumbleweed (but only if you have the required python2 libs grandfathered in). All variants are now close to feature parity with our CentOS offering and getting closer all the time. I would like to inviting linux proficient / ideally developer capable forum members to try these rpms out. Another prerequisite …

If anyone ends up looking to our AD improvements then the testing channel is the place to go.

@computergeek125
So as you mention not having much time I would concentrate on the windbind approach only and ensure that it works in the command line first. This will mostly likely involve removing all your prior sssd dealings. I must again apologies for the misleading docs here. We need an edit on those to reference the ‘reversal’ that I’ve indicated above. You are welcome to contribute this if you have the time.

Cheers.