IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
functionality directly from an application.
This is under a liberal license as we want application vendors to be
able to use the example code
(This used to be commit 8d848de45d75bf6ac69cb921e04abf36a66117c4)
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
Includes sambaUnixIdPool objectclass
Still needs cleaning up wrt to name space.
More changes to come, but at least we now have a
a working distributed winbindd solution.
(This used to be commit 824175854421f7c27d31ad673a8790dd018ae350)
New objectclass named sambaSamAccount which uses attribute
prefaced with the phrase 'samba' to prevent future name clashes.
Change in functionality of the 'ldap filter' parameter. This always
defaults to "(uid=%u)" now and is and'd with the approriate objectclass
depending on whether you are using ldapsam_compat or ldapsam
conversion script for migrating from sambaAccount to
sambaSamAccount will come next.
(This used to be commit 998586e65271daa919e47e1206c0007454cbca66)
primaryGroupID (rid). This is consistant with the move from 'rid' to ntSid
for the primary user identifier.
Also cope with legacy installations where primaryGroupID might have been
stored as 0.
Andrew Bartlett
(This used to be commit 0e432817cb927b41af7b49fb0b5081ffdb46f85e)
This patch removes 'non unix account range' (same as idra's change in HEAD),
and uses the winbind uid range instead.
More importanly, this patch changes the LDAP schema to use 'ntSid' instead
of 'rid' as the primary attribute. This makes it in common with the group
mapping code, and should allow it to be used closely with a future idmap_ldap.
Existing installations can use the existing functionality by using the
ldapsam_compat backend, and users who compile with --with-ldapsam will get
this by default.
More importantly, this patch adds a 'sambaDomain' object to our schema -
which contains 2 'next rid' attributes, the domain name and the domain sid.
Yes, there are *2* next rid attributes. The problem is that we don't 'own'
the entire RID space - we can only allocate RIDs that could be 'algorithmic'
RIDs. Therefore, we use the fact that UIDs in 'winbind uid' range will be
mapped by IDMAP, not the algorithm.
Andrew Bartlett
(This used to be commit 3e07406ade81e136f67439d4f8fd7fe1dbb6db14)
