samba - Jul 2018 - A few questions and propostions on the samba architecture

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
        uidNumber=get_next_free_uid()"
     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.

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
>         uidNumber=get_next_free_uid()"
>      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
because:
 - 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

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

On Fri, 13 Jul 2018 09:36:14 +0200
Anton Engelhardt via samba <samba at lists.samba.org> 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"
There is ongoing work to use LDAP instead of LDB, but it is very much a
WIP, I do not know of any woek to use SQLITE3.
>  2. ldap does not support any server side actions
>      1. Not possible to implement "on create class user
>         uidNumber=get_next_free_uid()"
Well no, but you can add a couple of attributes (Which are added and
used if you create users & groups from Windows ADUC) and then write a
script around 'samba-tool user create'
>      2. Only possible to define required/optional attributes
Not sure what you mean here, surely being able to update the schema is
a good thing.
>      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.
As I said, it can be done, you just need to script it yourself.
> 
> Or even use "CREATE VIEW" with "CREATE TRIGGER" to
implement fancy
> stuff like server side transparent password token validation.
Samba-tool will tell you if a password doesn't meet the required
complexity.
> 
> 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.
> 
I cannot see SQLITE3 ever being used, the LDAP work as been ongoing for
years and still doesn't work (last time I heard).

Rowland

On Fri, 13 Jul 2018 20:25:47 +1200
Andrew Bartlett via samba <samba at lists.samba.org> wrote:
> 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
> >         uidNumber=get_next_free_uid()"
> >      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
> because:
>  - 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)
Yes, but we still could have this problem if ADUC is installed on two
Windows PC's and two people create a user at the same time. Not that we
would have this problem on Win10 though.
 
> 
> My preference is to have these modules use the same RID+offset
> algorithm that sssd uses, and leverage the RID as a unique value.
Yes the RID would be unique, but the offset might not be, so you
could get collisions.
  
> 
> 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.
How about this, dump EVERY winbind backend except 'rid' and then obtain
the lower range at provision time.

Rowland

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.
CN=samdom,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System
msSFU30MaxGidNumber
msSFU30MaxUidNumber
msSFU30OrderNumber

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
>>          uidNumber=get_next_free_uid()"
>>       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
> because:
>   - 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
>

Got it, SQLITE3 KDB is dead.

While scripting is always a solution, not having events and simply 
binding them to an interval seems inefficient and open source gives us 
the opportunity to solve things the "proper" way. I know, there are 
people who love to Bodge.

As for the windows tools, assume I really rely on UID and GID for e.g. 
dovecot, setting up an account from the wrong machine, wrong user 
context would leave those fields blank.
IMHO automation is key, especially if you scale up your environment. 
Avoid human error at any cost, as humans ûsually don't think too much 
before they do.

What I mean by "Only possible to define required/optional attributes"
is
that LDAP offers CRUD, without any modification of the provided data on 
read/write trough methods. There are no constrains like in SQL.

SQL "CREATE VIEW" + "CREATE TRIGGER" is a very powerfull
method of
transparently running methods on data that is red or written in a table. 
Transparent is key here, that's why I mentioned it. It's not related to 
check the password complexity.


Am 13.07.2018 um 10:29 schrieb Rowland Penny via samba:
> On Fri, 13 Jul 2018 09:36:14 +0200
> Anton Engelhardt via samba <samba at lists.samba.org> 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"
> There is ongoing work to use LDAP instead of LDB, but it is very much a
> WIP, I do not know of any woek to use SQLITE3.
>
>>   2. ldap does not support any server side actions
>>       1. Not possible to implement "on create class user
>>          uidNumber=get_next_free_uid()"
> Well no, but you can add a couple of attributes (Which are added and
> used if you create users & groups from Windows ADUC) and then write a
> script around 'samba-tool user create'
>
>>       2. Only possible to define required/optional attributes
> Not sure what you mean here, surely being able to update the schema is
> a good thing.
>
>>       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.
> As I said, it can be done, you just need to script it yourself.
>
>> Or even use "CREATE VIEW" with "CREATE TRIGGER" to
implement fancy
>> stuff like server side transparent password token validation.
> Samba-tool will tell you if a password doesn't meet the required
> complexity.
>
>> 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.
>>
> I cannot see SQLITE3 ever being used, the LDAP work as been ongoing for
> years and still doesn't work (last time I heard).
>
> Rowland
>