samba - Feb 2023 - Group members via LDAP

On 08/02/2023 20:46, Troels Arvin via samba wrote:
> Hello,
> 
> Rowland Penny wrote:
>>> Anyway, when searching with ldbsearch, it also leaves out a group 
>>> member, if the member has the group as the primary group.
>>
>> If by 'primary group' you mean the users primaryGroupID
attribute has
>> been changed from '513', then this is to be expected. Every
user is
>> usually a member of Domain Users, but that group doesn't have any 
>> 'member' attributes. (and the users do not have a memberof
attribute).
> 
> The users indeed don't have 513 as primaryGroupID.
> 
> Maybe I need to iterate over all users and collect a set of 
> primaryGroupID values and then somehow look those up as groups; however, 
> there doesn't seem to be a group attribute mathing values I see for 
> primaryGroupID.
Why was the primaryGroupID changed ?
> 
> 
> 
>> What OS ?
>> What Samba version ?
>> The output of 'samba-tool testparm'
> 
> The Samba server runs Fedora Linux 37, Samba version 4.17.5.
If you are running a Samba AD DC on Fedora using the Fedora Samba 
packages, then you are using MIT kerberos, which Samba has marked at 
experimental.
> 
> The LDAP client is also Fedora 37, Samba client version also 4.17.5; 
> this host is joined to the Samba AD domain using "realm join
...".
This is, in my opinion, the wrong way of joining, you should have used 
'net ads join'.
> 
> 
> Output from "samba-tool testparm" on the server:
> ===========================================================> me at dc1
~]$ samba-tool testparm
> INFO 2023-02-08 21:08:55,860 pid:904 
> /usr/lib64/python3.11/site-packages/samba/netcmd/testparm.py #96: Loaded 
> smb config files from /etc/samba/smb.conf
> INFO 2023-02-08 21:08:55,860 pid:904 
> /usr/lib64/python3.11/site-packages/samba/netcmd/testparm.py #97: Loaded 
> services file OK.
> Press enter to see a dump of your service definitions
> 
> # Global parameters
> [global]
>  ? disable netbios = Yes
>  ? dns forwarder = 1.1.1.1 2.2.2.2 1111:2222:0:1::3 3333:4444:0:1::5
>  ? netbios name = DC1
>  ? realm = MYDOM.ORG
>  ? server role = active directory domain controller
>  ? workgroup = MYDOM
> ===========================================================
Where are the shares ?
> 
> Interestingly, "getent group mygroup" gives me the output I had 
> expected, i.e. it returns me a list of all members, including users who 
> have mygroup as primary group. I have, however, not yet managed to find 
> which code does which LDAP lookup(s) to find the information.
> 
I will not comment until I know why you have removed everyone from 
Domain Users, there is probably a good idea why this was done, but I 
cannot think of one.

Rowland

Hello,

Rowland Penny wrote:
> Why was the primaryGroupID changed ?
That must be a consequence of the users not having "Domain Users" as 
primary group.

> If you are running a Samba AD DC on Fedora using the Fedora Samba 
> packages, then you are using MIT kerberos, which Samba has marked at 
> experimental.
Ah, OK. This particular setup is not an important production 
installation. It's a setup to learn what is likely to be possible in a 
production setup in the future.

>> The LDAP client is also Fedora 37, Samba client version also 4.17.5; 
>> this host is joined to the Samba AD domain using "realm join
...".
> 
> This is, in my opinion, the wrong way of joining, you should have used 
> 'net ads join'.
I thought "realm" does more, when you want the Linux host to be well 
integrated into the AD using SSSD. I could be wrong.

> Where are the shares ?
The DC server has no shares. There is another server in the setup which 
exports directories in the form of NFS and SMB shares.

> I will not comment until I know why you have removed everyone from 
> Domain Users, there is probably a good idea why this was done, but I 
> cannot think of one.
In the setup, there are some Linux hosts joined with the AD. On the 
Linux host, it's nicer to have a simple, short, non-space-containing 
group name as the primary group, I thought. But if it results in all 
sorts of trouble, then I suppose it was a mistake.


As you may have seen in another mail in this thread, I've found a way to 
get a complete member list, even though it requires me to iterate 
through all groups explicitly asking for primaryGroupToken.

-- 
Regards,
Troels Arvin