ad_integration_computer_ou variable doesn't actually do anything? about ad_integration HOT 26 CLOSED

Guess what? It works with lower case! I can submit the tiniest of PRs to fix this in the realmd.conf.j2 template.

from ad_integration.

It appears the variable "ad_integration_computer_ou" does not do what I would expect it to do.

Per the README, it is:

"The distinguished name of an organizational unit to create the computer account."

As I painfully discovered over several days, setting this variable with an appropriate OU results in no change, and computers are joined to the domain in the default OU.

I looked through the code, and sure enough, "ad_integration_computer_ou" is only mentioned in the "realmd.conf.j2" file.

I've modified "tasks/main.yml" to correctly add the "--computer-ou" option to the "realm join" command,

@justin-stephenson is it necessary to not only add computer-ou = {{ ad_integration_computer_ou }} in realmd.conf, but also to add it to the realm join command?

@chuckmilam What version of ansible? What is the platform/version of your managed node? What is the version of AD?

but before I jump through what appears to be pages of hoops setting up a Fedora VM and "tox-lsr" and whatnot, I figured I'd ask here to make sure I'm on the right track in believing the "ad_integration_computer_ou" variable should do more than just update a value in "sssd.conf."

Do you mean realmd.conf instead of sssd.conf?

from ad_integration.

Sorry, yes, I did mean realmd.conf. That's what I get for looking at one file while typing about another.

I do see where the OU is defined in realmd.conf, but that doesn't help with the realm join command, which expects an argument of --computer-ou= to know what OU to create the computer account in.

Ansible version: Core 2.16.2, installed with pip in a python venv.
Managed nodes: CentOS Stream 9.
Domain Functional Level is Windows Server 2016

from ad_integration.

@justin-stephenson is it necessary to not only add computer-ou = {{ ad_integration_computer_ou }} in realmd.conf, but also to add it to the realm join command?

Both are not necessary, it can be done with either method

from ad_integration.

The behavior we are seeing indicates that the realmd.conf method has no effect, the newly joined systems end up in the default OU despite the computer-ou entry in /etc/realmd.conf.

Adding --computer-ou= to the realm join creates the systems in the appropriate OU.

Seems worthwhile to add this to the realm join command to ensure expected behavior in an AD domain.

from ad_integration.

@justin-stephenson is it necessary to not only add computer-ou = {{ ad_integration_computer_ou }} in realmd.conf, but also to add it to the realm join command?

Both are not necessary, it can be done with either method

Any idea why it isn't working, and how we can debug this?

from ad_integration.

This would be a bug/ticket against realmd, @sumit-bose may have some idea to troubleshoot further, -v realm command output at least.

from ad_integration.

Hi,

adding computer-ou in a proper section of realmd.conf works for me.

I used https://github.com/SSSD/sssd-ci-containers/ for testing. On the client instance I left form all configured domains, add a /etc/realmd.conf with the content:

[samba.test]
computer-ou = CN=Users,DC=samba,DC=test

and called

realm join -v samba.test

Now I verified that the computer object was created in CN=Users,DC=samba,DC=test, the default without computer-ou would be CN=Computers,DC=samba,DC=test.

What might be important here is that realmd reads /etc/realmd.conf and other config files only at startup and startup here does not mean the startup of the realm command line utility but the startup of the realmd daemon. The daemon is started automatically when the realm utility sends a DBus request and it will terminate itself automatically after 2 minutes of inactivity. But if /etc/realmd.conf is modified in between realmd will not reload the file and will not be aware of the changes. In this case it might be good to stop realmd explicit by calling systemctl stop realmd.service

HTH

bye,
Sumit

from ad_integration.

@sumit-bose so the proper steps are these?

• add computer-ou = MY OU to /etc/realmd.conf
• restart realmd
• realm join MY.DOMAIN

The role does write realmd.conf and calls the handler to restart - https://github.com/linux-system-roles/ad_integration/blob/main/tasks/main.yml#L68-L74

- name: Generate /etc/{{ __ad_integration_realmd_config }}
  template:
    src: "{{ __ad_integration_realmd_config }}.j2"
    dest: /etc/{{ __ad_integration_realmd_config }}
    backup: true
    mode: 0400
  notify: Handler for ad_integration to restart services

The handler is https://github.com/linux-system-roles/ad_integration/blob/main/handlers/main.yml#L3 where __ad_integration_services is defined in https://github.com/linux-system-roles/ad_integration/blob/main/vars/main.yml#L12 as [realmd]

@chuckmilam In the Ansible logs, do you see the handler task being run before the realm join task? If not, then I think the role cannot use an "asynchronous" handler - I think the realmd.conf task has to not use a notify, but instead register the result of the task, then explicitly call service restart immediately after updating realmd.conf if realmd.conf changed.

from ad_integration.

It does appear the realmd.conf file is written out from the Jinja template and the Handler for ad_integration to restart services handler is called before the realm join.

However, in our Windows 2016 AD environment, unless the realm join is fed the --computer-ou= argument, the newly-joined systems will end up in the default OU, which makes our AD admins grumpy.

Would it not be a decent belt-and-suspenders move to simply do both the realmd.conf and the realm join --computer-ou?

from ad_integration.

It does appear the realmd.conf file is written out from the Jinja template and the Handler for ad_integration to restart services handler is called before the realm join.

Yes. I didn't see this before, but the role calls meta: flush_handlers just after configuring realmd.conf - https://github.com/linux-system-roles/ad_integration/blob/main/tasks/main.yml#L76

However, in our Windows 2016 AD environment, unless the realm join is fed the --computer-ou= argument, the newly-joined systems will end up in the default OU, which makes our AD admins grumpy.

Would it not be a decent belt-and-suspenders move to simply do both the realmd.conf and the realm join --computer-ou?

I would like to make the role work properly regardless of the version of realmd/platform/Windows. I would also like to understand why the role isn't working, since it appears to be following the correct procedure as described by @sumit-bose at #87 (comment), and I would also like to understand if there is a bug in realmd/realm join since it does not appear to be working as documented, and fix realmd/realm join if necessary.

So @sumit-bose this looks like a bug in realmd/realm join. What information do you need for debugging?

from ad_integration.

.... I would also like to understand if there is a bug in realmd/realm join since it does not appear to be working as documented, and fix realmd/realm join if necessary.

Understood. Hey, while we're at it, maybe we can get realm to accept a password via CLI (not great) or ENV (better)? Ha!

Glad to help with any debugging info you need from my end.

from ad_integration.

.... I would also like to understand if there is a bug in realmd/realm join since it does not appear to be working as documented, and fix realmd/realm join if necessary.

Understood. Hey, while we're at it, maybe we can get realm to accept a password via CLI (not great) or ENV (better)? Ha!

@sumit-bose or @justin-stephenson - where should realmd/realm bugs and RFEs be filed?

Glad to help with any debugging info you need from my end.

from ad_integration.

@chuckmilam Could you provide realm join -v output here in the failure scenario: when the computer-ou was added to realmd.conf and realmd restarted ? Or you can email to [email protected] if you prefer.

from ad_integration.

@chuckmilam Could you provide realm join -v output here in the failure scenario: when the computer-ou was added to realmd.conf and realmd restarted ? Or you can email to [email protected] if you prefer.

Hi,

additionally, please add the output of journalctl -u realmd as well.

Thanks.

bye,
Sumit

from ad_integration.

Hi all: I sent the logs to @justin-stephenson at his Red Hat E-Mail.

from ad_integration.

Thank you for the logs @chuckmilam

I see that realmd calls adcli join but it does not add on the --computer-ou argument as expected when reading the computer-ou setting from realmd.conf such as:

[samba.test]
computer-ou = CN=Users,DC=samba,DC=test

Can you double-check that the changes in /etc/realmd.conf includes the correct section name in brackets, matching the domain name/realm name as seen in realm join -v output. Perhaps the AD integration role is discovering the incorrect domain/realm name.

It might be interesting to see if any other realmd.conf changes get detected or if it is only the computer-ou setting.

from ad_integration.

@justin-stephenson /etc/realmd.conf on my test VM I realm joined with the latest ad_integration system role appears to be a correctly-formatted .ini file.

The domain/realm name section looks correct, domain name in all caps. I can sanitize and send to you via email if you like.

from ad_integration.

@justin-stephenson /etc/realmd.conf on my test VM I realm joined with the latest ad_integration system role appears to be a correctly-formatted .ini file.

The domain/realm name section looks correct, domain name in all caps. I can sanitize and send to you via email if you like.

Okay thanks, I'm not sure what the issue is - @sumit-bose I will send you the logs if you don't mind taking a look.

from ad_integration.

Ok, here's a possible issue:

Instead of [samba.test] I have it as: [SAMBA.TEST] in /etc/realmd.conf.

When I do a realm join -v, I get:

* Successfully discovered: samba.test (Note lower-case domain name)

I know the CAPS matters when doing a manual realm join, in particular when passing the domain join user, ex:

realm join -v -U [email protected]

I wonder if I should change the case in the realm name section header and try it again.

from ad_integration.

I wonder if I should change the case in the realm name section header and try it again.

Hi,

yes, please try with lower-case characters. I guess this would work, in that case I'll try to figure out how to make the lookup case-insensitive.

bye,
Sumit

from ad_integration.

Is there something we need to do in the ad_integration role? Enforce that the ad_integration_realm is all upper case? Check that ad_integration_realm matches some other value?

from ad_integration.

Is there something we need to do in the ad_integration role? Enforce that the ad_integration_realm is all upper case? Check that ad_integration_realm matches some other value?

Hi,

no, lower-case would be better. I just found that it is even documented in the realmd.conf man page "These realm specific sections should always contain the domain name in lower case as their section header."

bye,
Sumit

from ad_integration.

Guess what? It works with lower case! I can submit the tiniest of PRs to fix this in the realmd.conf.j2 template.

Excellent - thanks!

from ad_integration.

@chuckmilam did you want to submit your patch as a PR to https://github.com/linux-system-roles/ad_integration/pulls ?

from ad_integration.

It should be there now. Hope I got it right, I'm used to working with a different system, so I was muddling around in the GitHub web GUI for expediency.

from ad_integration.