[Samba] A few questions and propostions on the samba architecture
engelhardt.anton at gmail.com
Fri Jul 13 09:14:02 UTC 2018
That explains why there is so little information on ldb and sqlite.
From my pov sqlite just seemed interesting, as it has a well known
syntax and the ability to embedd a transparent logic layer. As there is
no effort to use sqlite (or sql) in the future , I just burried that path.
As for compability I would strongly suggest to stay where Microsoft left
off, before killing the "UNIX Attributes" tab in Windows10 RSAT.
I understand the disire too keep things as compatible as possible, but
on the other hand open source software usually offers way more flexibility.
in my head there are 2 solutions, which should be completly client
compatible and introduce no behavioral change:
1. interval poll all class=user objects where uid=NULL, get values from
above mentioned entries, compose an update transaction (thats the
"Just write a powershell script" variant)
2. same as 1, just with some sort of trigger (or better filtered
subscriptions) for external scripts in samba
What I also have in mind with this architecture would be something like
password tokens, but keep in mind this is just a thought.
The password passed on to ldap auth could be, if the user has an
attriblue like "requreToken", stripped of like the last 6 chars, which
represent the token. The password is matched against the hased password
in the ldap user entry, the token is processed in an external app, if
both are a success, login is fine. This propably would require kerberos
tickets, as the password is constantly changing, but would introduce a
lot of flexibility, for those who dare.
In terms of internal scripting, is there already anything in samba?
Am 13.07.2018 um 10:25 schrieb Andrew Bartlett:
> On Fri, 2018-07-13 at 09:36 +0200, Anton Engelhardt via samba wrote:
>> Due to a few problems I encountered I had a tiny look at the samba code
>> and gut a few questions, statements and propositions. Please by all
>> means, correct me if I got something wrong.
>> 1. besides filestore for shares and config files samba uses ldb as an
>> exclusive storage backend
>> 1. LDB supports TDB, LDAP and SQLITE3 backend
>> 2. Samba hard codes to TDB files like "sam.ldb"
>> 2. ldap does not support any server side actions
>> 1. Not possible to implement "on create class user
>> 2. Only possible to define required/optional attributes
>> 3. ldap service is provided trough ldb-ldap -> tdb
>> I don't know if it is a good idea, but when using something like sqlite3
>> it would be possible to use "CREATE TRIGGER", to perform some automation
>> magic on server side, like giving out uidNumber and gidNumber.
>> Or even use "CREATE VIEW" with "CREATE TRIGGER" to implement fancy stuff
>> like server side transparent password token validation.
>> Depending on my undarstanding of the current architecture and the state
>> of the ldb sqlite backend this would seem like the easiest approach,
>> correct me if I'm too far off.
> Using ldb_sqlite wouldn't help, as we don't use it in a smart way, it
> was added (and then left unmaintained, we really should remove it) in
> the hope of getting transaction support, but instead that was gained
> via tdb.
> The uidNumber and gidNumber changes you desire are reasonable, and we
> could do those in the samldb module or similar. We haven't done so
> - at the time we were trying to match Windows AD behaviour exactly.
> - the allocation needs to be stateless or manage the free id pool like
> the RID pool.
> (Because we need to ensure that two users created at the same time on
> different servers don't overlap uids)
> My preference is to have these modules use the same RID+offset
> algorithm that sssd uses, and leverage the RID as a unique value.
> The key would be to make this relatively compatible with the settings
> used in winbindd on the file server, so if that RID base were
> inappropriate another could be chosen via idmap_rid.
> However I've not had the time to implement this, sadly.
> Andrew Bartlett
More information about the samba