document installation of desktop-profiles on AD

[ibotty]

We are running a Samba DC and would like to use Fleet Commander. How can we add the desktop profiles? I did not find any documentation. Is installing https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/schema.d/75-deskprofile.ldif enough to get started? I'd certainly like to enhance the documentation after we get it running.

[olivergs]

Hi @ibotty. For using fleet commander you need either FreeIPA or Active Directory. Samba DC is not enough as FC needs the directory service to save and retrieve the metadata for the profiles.

[olivergs]

To be more exact. In FreeIPA a custom plugin is used to store the profile information. The one you linked is the plugin used, but FC relies in FreeIPA client connection to retrieve the profile information.

In the case of AD, you need support for GPOs in the directory service. Never used it in Samba DC, but I suspect there is no support for GPO.

[ibotty]

Oh, there is support for GPOs in Samba DC. They work fine. Maybe I am missing something.

[olivergs]

If there is support for the GPOs in Samba DC then fleet commander admin should be able to store and retrieve the profiles. You need to install FC Admin in a fedora machine that is part of the domain, and log in into cockpit with a domain admin user. If all goes well, FC Admin should detect the domain server.

[ibotty]

Thanks for your help.

So there is no need to install any profile LDAP schema? That would be great. Unfortunately on my Fedora 34 with fleet-commander-admin-0.15.1-3.fc34.noarch and cockpit-254-1.fc34.x86_64 I only get

Error setting global policy

in the UI and

fleet-commander-admin[6823]: ERROR:root:Error setting global policy to 1: 'NoneType' object is not subscriptable

in the journal log.

My /etc/xdg/fleet-commander-admin.conf is

[admin]
data_dir        = /usr/share/fleet-commander-admin
tmp_session_destroy_timeout = 60
log_level = debug

but I don't see any other output.

How can I debug it further? I am kind-of lost.

[olivergs]

With the log level to debug, you should be able first to find if FC is detecting the domain as an AD or a FreeIPA. It should be detected as a AD or as something different from AD. It relies in the realmd service to get the domain and the server type.

Look for something like: FC: Realm details: . The default value is "ipa", but in your case should be "active-directory" or a different value. If it detects as active-directory, then it will use the AD Connector, that is the one that uses the GPOs.

If it says something different we can try to force it as active directory, but that would need some hacky modification at

fc-admin/admin/fleetcommander/fcdbus.py

Line 132 in 9b5b8c3

if server == "active-directory":

and you can change active-directory for the value you got and check if it works. The file should be in /usr/share/fleet-commander/python/.

If it do not work, then the problem requires more in depth work.

[ibotty]

Unfortunately it does not seem to pick up the log level setting. Even setting it explicitly in logging.config(level=logging.DEBUG, ...) did not make a difference. It seems to get filtered out somewhere else. I replaced some relevant logging.debug to logging.error to have more insight:

ERROR:root:Using SAMBA 3 SMB connection (Internal)
ERROR:root:FC: realmd queried. Using realm object /org/freedesktop/realmd/Sssd/redacted_example_com_1
ERROR:root:FC: Realm details: redacted.example.com (active-directory)
ERROR:root:Activating Active Directory domain support for redacted.example.com
ERROR:root:Initializing domain redacted.example.com AD connector
ERROR:root:Started session checking
ERROR:root:Getting hypervisor configuration
ERROR:root:Getting global policy
ERROR:root:Connecting to AD LDAP server
ERROR:root:Getting LDAP service machine name
ERROR:root:LDAP server: ad-01.redacted.example.com
ERROR:root:Initializing LDAP connection to ad-01.redacted.example.com
ERROR:root:Binding LDAP connection
ERROR:root:LDAP connection succesful
ERROR:root:Getting global policy from AD
ERROR:root:Getting data from AD LDAP. filter: (displayName=_FC_GLOBAL_POLICY__DO_NOT_MODIFY)
ERROR:root:Checking hypervisor configuration
ERROR:root:Setting policy to 1
ERROR:root:Connecting to AD LDAP server
ERROR:root:Getting LDAP service machine name
ERROR:root:LDAP server: ad-01.redacted.example.com
ERROR:root:Initializing LDAP connection to ad-01.redacted.example.com
ERROR:root:Binding LDAP connection
ERROR:root:LDAP connection succesful
ERROR:root:Getting data from AD LDAP. filter: (displayName=_FC_GLOBAL_POLICY__DO_NOT_MODIFY)
ERROR:root:Connecting to AD LDAP server
ERROR:root:Getting LDAP service machine name
ERROR:root:LDAP server: ad-01.redacted.example.com
ERROR:root:Initializing LDAP connection to ad-01.redacted.example.com
ERROR:root:Binding LDAP connection
ERROR:root:LDAP connection succesful
ERROR:root:Saving new profile
ERROR:root:New profile UUID = {1A207B06-DBA7-4017-9D14-1BAD53E31E5F}
ERROR:root:Getting LDAP service machine name
ERROR:root:LDAP server: ad-01.redacted.example.com
ERROR:root:Preparing security descriptor
ERROR:root:Connecting to AD LDAP server
ERROR:root:Getting LDAP service machine name
ERROR:root:LDAP server: ad-01.redacted.example.com
ERROR:root:Initializing LDAP connection to ad-01.redacted.example.com
ERROR:root:Binding LDAP connection
ERROR:root:LDAP connection succesful
ERROR:root:Error setting global policy to 1: 'NoneType' object is not subscriptable

So it seems to fail in admin/fleetcommander/fcad.py's getUser at self.connection.search_s with the following arguments:

search_s('CN=Users,DC=redacted,DC=example,DC=com',2,'(&(objectclass=user)(CN=myuser))',['cn', 'objectSid'])

That makes sense, because users in our directory are in a different OU. Unfortunately that's not all. Our CN is also not the uid that one logs into. Patching that, I run into another problem though.

[olivergs]

The main development for AD in Fleet Commander was done with a Windows Server 2012 instance 2-3 years ago, with the default settings (Users in default OU, etc.)

It was never tested against Samba DC, but seems the main "problems" are basicly changes in domain configuration.

Maybe with some adjustments in the fcad.py module you could make it work. Changing the default queries to LDAP is what I think that should be done to get it working for your case.

If at some point you make it work, please consider contribute your changes and thoughts as they can be included to enhance compatibility.

Thank you for stopping by.

[ibotty]

Thank you for your explanation. I will certainly contribute changes when I can make it work. I'll have a look at how I can get the user's OU and maybe additional hardcoded paths from the server.

[olivergs]

If you need some clarification on how is done something or more details on where to add/modify any part of the code, please, ask me. :)

[ibotty]

Thank you. I will.