[Pkg-samba-maint] Bug#1068360: samba-gpupdate should be in samba-common-bin

[Patrick Hibbs]

On 5/14/24 10:50, Michael Tokarev wrote:
> 09.04.2024 15:13, Patrick Hibbs wrote:
>
>> The net command in samba-common-bin, specifically: `/usr/bin/net ads 
>> join`, allows joining the domain without having the main samba 
>> package installed.
>
> Does `net ads join` need any python stuff?

Running [ /usr/bin/net ads info ], [ /usr/bin/net ads join ], and [ 
/usr/bin/net ads keytab create ] with strace and grepping for python 
stuff doesn't reveal anything. I don't see any calls to the python 
interpreter nor a direct link being resolved by ld.

I do see ld resolving a library called [ 
/usr/lib/x86_64-linux-gnu/samba/libads-samba4.so.0 ] in addition to 
various others. Which seems to indicate /usr/bin/net uses only native 
binaries for ads related stuff. (Not that it couldn't change in the 
future....)

>
>> sssd-ad with it's ad_update_samba_machine_account_password flag set 
>> to true in it's config will keep the machine creds up-to-date without 
>> the main samba package installed.
>>
>> samba-gpupdate handles downloading and managing group policies on the 
>> domain member, just like the gpupdate utility under Windows.
>>
>> samba-gpupdate is just a python script. It's dependencies are in 
>> python3-samba. Which samba-common-bin already depends on. That script 
>> is invoked either by winbind,
>>
>> the alternative for sssd systems (and not packaged in Debian) 
>> oddjob-gpupdate (https://github.com/altlinux/oddjob-gpupdate), or 
>> manually by the system admin. (The script takes arguments similar to 
>> the Windows utility.)
>
> Okay, I don't know most of this.
>
> But we come across another idea meanwhile.
>
> How about we split out another package out of samba (and 
> samba-common[-bin]),
> named samba-ad?
On a personal note, I'd just call such a package "samba-ad-client" to 
avoid confusion. "samba-ad" could imply domain controller functionality 
to the uninitiated, and there would undoubtedly be complaints about 
"samba-ad" vs. "samba-ad-dc" being different. I also could have sworn I 
saw some other distro using "samba-ad" as a package name for their 
domain controller support, but I can't seem to find it now....
>
> The idea is to have minimal samba-common[-bin] to contain stuff 
> absolutely
> necessary for smbclient and all servers (without python deps), samba 
> binary
> package (also without python deps) being a minimal stand-alone file 
> server,
> samba-ad (depends on python and samba) being AD part of the story, and
> samba-ad-dc is the, well, AD-DC part.
>
> This way, samba-gpupdate will be part of samba-ad package, instead of 
> samba-common[-bin].
>
> I'm not yet know if it is doable, but at first look I think it is.
>
> If you can help to better figure out what is what, it would be great.
>
> Maybe samba-ad should not depend on samba though, to suit your needs
> expressed in this bug report.

The dependencies would probably be best discovered by examining the 
expectations and capabilities of AD.

Group policies in AD can be applied to Domain Controllers, "Domain 
Members / Member Servers" (I.e. Domain Joined Machines), Users, and 
Groups. They also have the ability to apply selectively based on various 
criteria from various sources. (WMI queries on the local machine, 
environment vars, filesystem data, LDAP attributes, group membership, etc.)

These policies are declared (think C style forward declarations) by the 
domain in LDAP, and linked to LDAP OUs. Which must be enumerated by the 
domain joined machine's group policy client. (I.e. samba-gpupdate) This 
is expected to happen on a regular recurring basis (generally once an 
hour but this is configurable) and on reboot to "refresh" the policies. 
I.e. Check for policy updates.

The actual policy definition (I.e. what should actually be done) for 
each policy is stored in the SYSVOL SMB share on each Domain Controller. 
Once the group policy client has enumerated what policies to apply, it 
is expected to connect to (any) domain controller over SMB (using the 
machine's domain account, i.e. machine's kerberos creds in 
/etc/krb5.keytab) to download the policy definitions. These definitions 
are cached locally, and the LDAP records indicate when a change has 
occurred. (So these SMB connections don't always occur alongside each 
LDAP "refresh". This is to reduce load on the DCs.)

Further, depending on the applied policies, additional SMB connections 
can be made. For example, file and script policies can store stuff in 
the SYSVOL share for client deployment. These connections can happen on 
every user login, (If it's a User policy), or on every client boot. (If 
it's a Computer policy.)

It is possible for some policies to apply to an SMB server. In fact, 
samba expands on this to allow updating and controlling the contents of 
/etc/samba/smb.conf via it's own group policy extensions.

There's also the possibility that a script policy could try to upload 
something to the client manually. I.e. Under Windows, it's possible to 
define a policy that runs a script that could output it's result to a 
text file that then gets uploaded to another domain joined machine over 
SMB. Using any domain account, or possibly a local account, to 
authenticate to the other machine. The same is possible under Linux. 
(Although, such a script policy would need to invoke smbclient manually 
and therefore that script policy would be scoped to only apply on a 
Linux machine.)

Also under Windows (but not really applicable to Linux by default) is 
the possibility for a policy to try to execute commands against the 
Administrative SMB Shares on the client. (I.e. Hidden SMB shares that 
expose any disk / partition with a drive letter assignment to the 
network in the form of [ smb://<HOSTNAME>/<DRIVE_LETTER>$/ ].) This is 
disabled by default on modern Windows versions for security reasons, but 
historically it was enabled by default, and many domains apply group 
policies that re-enable it on machines that join them. (Old habits die 
hard.)

So at bare minimum, any "samba-ad" client package would need to depend 
on python3-samba (samba-gpupdate's own requirements), and 
samba-common-bin. (For smbclient libraries. Which pulls in kerberos and 
ldap.) Further, samba-ad-dc would need to depend on the "samba-ad" 
client package. (As DCs are themselves group policy clients.)

The samba file server package could depend on the "samba-ad" client 
package for applying policies to the server's smb.conf, but there's no 
real reason to have the "samba-ad" client package dependent on the file 
server package. As there's no group policies that require SMB shares on 
the group policy client by default.

>> Personally, I have samba-gpupdate invoked as an hourly cron job. 
>> Which is pushed out to the client machines via Samba's crontab group 
>> policy extension. (So after the initial join, I have to invoke 
>> samba-gpupdate myself once, but after that,
>>
>> cron is configured automatically to call it based on the policy that 
>> was pulled.) Of course, this will break if the host gets put into an 
>> OU in the domain that removes the cronjob, but that can be fixed by 
>> recalling samba-gpupdate after fixing the policy on the domain side. 
>> (And can even be triggered via a script calling ssh.)
>
> Yes, this can be done too, for sure.  I'd use a systemd timer for this
> stuff, and ship it disabled.
>
> Thanks,
>
> /mjt

Yeah, I could do it that way. I was just trying to do it in a way that 
wouldn't get overwritten somehow. But my current method has it's own flaws.

The main thing is that domain joined machines are expected to be 
configured to do this automatically upon joining a domain. (I.e. Under 
Windows, joining a domain implicitly enables the group policy client 
without any user interaction what so ever.) Such a systemd timer would 
probably be better (i.e. implement the expected behavior) if it was 
enabled by default, but had a conditional check for the machine to be in 
domain member / controller mode. (I.e. smb.conf: security = ADS or 
security = active directory domain controller.)

Have a good Day!

-Patrick Hibbs