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
