Problems With Realm Joined AD and WIndind KRB5. related?

Rocky Linux Tech Help
1

Dear all,

I have having problems with a machine Rocky8.4 joined to AD with SSSD
Selected Users are able to log on. Great!

But Winbind wont start continuously refusing with “could not fetch our SID” and “unable to initialize domain list”

Despite being able to log on kinit with username replies with KDC Reply did not match expectations

Its an old domain which is being upgraded soon, this is a key part of the system renovations.

Everything else is working but the verfications of users against Samba not working means the shares are just refusing users in the WIndows Domain …

There is a huge disparity online as to what the smb.conf should look like.

Does anyone have this working - able to assist would be really gleefully accepted.

2

If you are running winbind (and if you have ‘security = ADS’ set in smb.conf, you must), you do not need sssd.

Please post the output of ‘testparm -s’

3

Fundamentally, samba depends on winbind to resolve windows SIDs to linux UIDs and for this winbind must be joined to the domain. As @hortimech has pointed out, the best (i.e. easiest) way to do this is to join the domain with winbind and not sssd.

However, it seems to be possible to join with both sssd and winbind as long as both services keep each other informed about the machine password changes. This is described in a SUSE KB article: Configure Samba File Server with AD Users | Support | SUSE.

The following are the [global] section settings in smb.conf that I added or changed from the defaults on a Rocky 9 test system joined with both sssd and winbind. Since I have been using RID-based mapping in my configurations, the only difference from my winbind-only config is using nss instead of rid for the ID map.

        workgroup = {SHORT_DOM}
        security = ads
        realm = {MY.DOMAIN.TLD}
        kerberos method = system keytab
        vfs objects = acl_xattr
        map acl inherit = yes
        store dos attributes = yes
        idmap config {SHORT_DOM} : range = 800200000-810200000
        idmap config {SHORT_DOM} : backend = nss
        idmap config * : range = 1000000-1100000
        idmap config * : backend = tdb
        winbind enum users = no
        winbind enum groups = no
4

WOW, what a kludge.
Active Directory is the source of truth, but there is no need to join it twice on the same machine. If you have shares (smbd is running) and have ‘security = ADS’ set in smb.conf, then you must run winbind,. If you have winbind running and use the ‘rid’ idmap backend, then all your AD users & groups become local Unix users and groups, so why would you need sssd, just what is the point to running something you really do not need ?

You might want to read ‘man smb.conf’, three of your lines are defaults, you are restricting to whatever is in the keytab and finally, your default range ‘*’ is set to ‘1000000-1100000’, which gives you potentially 100000 users and groups, a bit large when you consider it is meant for the BUILTIN users & groups, the Well Known SIDs and anything outside the main domain (so ‘0’ really), there are less than 200 of them.

5

Thanks for your replies. Thanks as ever Linde - it seems we might be on convergent paths infra wise :slight_smile: …

As Hortimech mentioned, I’d prefer to use a single authentication mech - IF I can get it to work. Hopefully something I’ve done wrong. Perhaps not by install Winbind when I install Realmd, Samba-Common, SSSD, etc – had Winbind been present at the time would the join have set up Winbind? having never tried it before I don’t know.

Forgive image output of testparm - I am looking at the wildcard - as I presumed that was correct syntax?

testparm
testparm582×520 54 KB

6

OK, I typed out your testparm output so I can comment on it, it would have saved me that if you had cut & pasted it.

I have also slightly rearranged it.

[global]
workgroup = SPLODGE
security = ADS
realm = SPLODGE.LOCAL
dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab

winbind use default domain = yes
winbind refresh tickets = Yes
vfs objects = acl_xattr
map acl inherit = Yes
idmap config * : backend = tdb

Nothing wrong with those lines, Apart from you appear to be using ‘.local’ as your TLD, that is reserved for Bonjour and Avahi.

Sorry, but it all goes downhill from there.

winbind enum groups = yes
winbind enum users = yes

You do not require the two ‘enum’ lines, Samba will work without them,
if you use ‘getent’ you just have to use it in the format:
‘getent passwd USERNAME’

winbind nss info = rfc2307

That line is only used with the ‘ad’ idmap end.

create mask = 0664
directory mask = 0775

Those are ‘old school’, either set the directory permisions with setfacl
or from Windows

map archive = no

Not much point in setting that, it is overridden.

[share]
comment = Shared Folder
path = /var/share/share
read only = no
valid users = SPLODGE.LOCAL\DOMAIN USERS

I suggest that you do not use ‘valid users’, use setfacl or Windows,
but if you must use it, the Value would be ‘SPLODGE\domain users’
(including the single quotes).

Finally the really big one:

You have:

idmap config * : backend = tdb

It isn’t enough.

You need something like this:

idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config SPLODGE : backend = rid
idmap config SPLODGE : range = 10000-999999

If you want your Samba users to logon directly to the computer,
they will require a shell that allows them:

template shell = /bin/bash

And a home directory to log into:

template homedir = /home/%U

Once the smb.conf is setup correctly, you will not need sssd, so you can turn it off.

Questions ?

7

Hi Hortimech,

Thanks for that. Sorry I could not paste, the machine is running in a segmented network and I am working remotely with no clipboard access. I should have written it out for you, but was more mindful of an accidental error confusing things. I do appreciate your time however.

I need to try a few things here.

However in answer to the changes you’ve made … understood.
However the users get a home directory with make-homedir
in this case they won’t be logging in only the wheel / root user has access. - so a homedir a mute in any case :wink:

What does idmap config * mean - ?
I will change the later lines - however - I am wondering how will they address Winbind thinking its not joined - what is my SID - unable to initialise domain list - can that error be caused by those lines?

Thanks again

8

Lets deal with 'What does ‘idmap config *’ mean:

When you run Samba in a domain, you deal with (at a minimum) two domains, the default (or ‘*’ domain) and the ‘DOMAIN’ domain.

The default ‘*’ domain is meant for the BUILTIN users & groups, Well known SIDs and anything not in the ‘DOMAIN’ domain (which is usually 0), you only really need 200 for the default domain, so the 3000-7999 range is well capable of dealing with all eventualities.

The DOMAIN’ domain is where your AD users and groups are mapped to Unix IDs, the ‘rid’ idmap backend calculates the Unix IDs from the user or group RID and the low range you set in smb.conf. From the suggested range in my example, the Domain Users group would always be 10513:
10513 = 10000 + 513
If you use trusts, you can have further ‘DOMAIN’ blocks, but the ranges must be different and cannot overlap. As for where ‘DOMAIN’ comes from, it just a place holder for your NetBIOS domain name (also known as the workgroup)

The next thing is, you are going to have to leave the domain with sssd and then join the domain with Winbind, you do this (if you are unaware) with ‘net ads join -U administrator’ (or another user with permission to join).

I suggest you set up a VM to test this, it is very easy, but better safe than sorry.

9

OK - I was worried I’d have to leave the domain with SSSD.
Its a massive 20TB VM .

I am going to test!

Thanks !!!

10

It might be enlightening to consider why someone might choose these settings.

Also, I wholeheartedly agree that combining sssd+winbind is an awful mess. Based on my own testing, I only have one scenario where I feel like it makes sense – this would involve a server where users needed both login access and samba shares.

For me the big issue amounts to two sssd features which winbind lacks last time I checked:

  1. Automatic private groups
  2. Site awareness

It’s a huge pain having every user’s primary group be “Domain Users” (or any group common to everyone). Unfortunately the sssd+winbind mess only partially resolves this – logged in users have their automatic private groups as primary but samba still assigns “Domain Users” on everything it does.

11

Yes, using sssd with winbind is a mess, mainly because they both basically do the same thing, which isn’t surprising because the were both written initially by the same person.
If you just want login, then sssd is great for that, but if you want a Unix domain member with shares, you need winbind which will give you login and shares.

If you use the ‘rid’ idmap backend, you get a user private group e.g. the user ‘fred’ would also have a group ‘fred’. There is ‘sites’ built into AD and can be used with Samba AD.

Every users Primary Group being ‘Domain Users’ isn’t a Samba thing, it is a Microsoft AD thing, Microsoft relies on every users primary group being ‘Domain Users’.

The problem is, as far as I can see, that Winbind was written to connect AD and then sssd was written to connect to freeipa. Freeipa isn’t AD, so of course there will be differences in the way they work, you should use the one that is best for the system you are running…

12

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.