Univention Bugzilla – Bug 34221
Samba4 @school test: SID allocation
Last modified: 2018-11-01 19:52:32 CET
In UCS@School domains SID allocation is managed by the Univention Directory Manager. A test case should be implemented to verify this: When a user or computer account is created via UMC/UDM, the sambaSID needs to be set directly by the UDM. Three possible tests come to mind in this context: * An account created in UMC/UDM must carry a sambaSID which has the SID prefix of the domain. * The sambaSID of the test account must not change at any time in OpenLDAP. I.e. it must be verified that the sambaSID remains the same after the account was created and while it is replicated by the S4 Connector. * After creation of a test account via UMC/UDM, the objectSID of the replicated account object must be identical in the Samba4 directory of a school server and of the master. Maybe the test cases for the first two facts can be combined and first stop the S4-Connector before the creation of the account to have a defined state where the initial sambaSID can be detected. Then the S4 Connector must be started again to verify that (Samba4 objectSID == initial sambaSID) after the replication converged. While the last fact (objectSID@master == objectSID@slave) might look like a corollary of the former two, it should be explicitely checked as well to safeguard against the complexities of the UCS@school setup.
Maybe the test should also check that the nextRID counters in Samba4 remains unchanged.
r53956: * Bug #34221: 90_ucsschool/96_samba4_sid_allocation: test the SambaSID allocation. r54192: * Bug #34221: 90_ucsschool/96_samba4_sid_allocation: also check the RID; small changes; 90_ucsschool/essential/test_samba4.py: added method for UMC connection. Note: * An account created in UMC/UDM must carry a sambaSID which has the SID prefix of the domain. --> I believe covered by the tests for Bug #33677 (60_samba_sid_user, 60_samba_sid_group)
Ok, please also check that the values of univention-s4search '(objectClass=rIDSet)' rIDNextRID stay the same (Comment 1).
(In reply to Arvid Requate from comment #3) > Ok, please also check that the values of > > univention-s4search '(objectClass=rIDSet)' rIDNextRID > > stay the same (Comment 1). Please comment on the following: 1. rIDNextRID is only applicable to the Domain Controllers and each has its own unique value (http://support.microsoft.com/kb/305475/en-us) 2. The ID is only set and modified when '96univention-samba4.inst' is executed. 3. Therefore, should the test do the re-join by running the '96univention-samba4.inst' and check that 'rIDNextRID' after the re-join stays the same (i.e. test of Bug #34754)? 4. If so, I guess better to do it as a separate test. Or if you've meant something else -> please specify in more details.
> 1. rIDNextRID is only applicable to the Domain Controllers and each has it > own unique value (http://support.microsoft.com/kb/305475/en-us) Yes. > 2. The ID is only set and modified when '96univention-samba4.inst' is executed. Samba4 increases rIDNextRID whenever it is asked to create a new account locally. This is only done at creation time and if no objectSID has been specified yet. The code in 96univention-samba4.inst only takes care to save+restore the counter in the case where someone re-joins the system. > 3. Therefore, should the test do the re-join by running the > '96univention-samba4.inst' and check that 'rIDNextRID' after the re-join > stays the same (i.e. test of Bug #34754)? No, that would be a different/other test (good point..) > 4. If so, I guess better to do it as a separate test. > Or if you've meant something else -> please specify in more details. Yes, I agree, but let's simply skip this here. The tests here are about account creations, not about rIDNextRID/RID Set preservation during re-join.
OK, added local check: r59132: * 96_samba4_sid_allocation: check that 'rIDNextRID' remains the same in Samba after user creation (Bug #34221).
The tests checks the following with a new user. A new computer/group is not part of the test. > * An account created in UMC/UDM must carry a sambaSID which has the SID prefix > of the domain. OK: Covered by 60_samba_sid_user and 60_samba_sid_group > * The sambaSID of the test account must not change at any time in OpenLDAP. > I.e. it must be verified that the sambaSID remains the same after the account > was created and while it is replicated by the S4 Connector. TODO > * After creation of a test account via UMC/UDM, the objectSID of the replicated > account object must be identical in the Samba4 directory of a school server and > of the master. OK: local check if (single) master OK: remote check if member/slave > * Check that the nextRID counters in Samba4 remains unchanged. OK: Samba4 rIDNextRID unchanged by user creation TODO: Samba4 rIDNextRID unchanged by s4-connector user sync Nitpicks: - Exit codes on external commands are disregarded - Raw search in S4 instead of `univention-s4search` - Manual user-DN mapping instead of S4 search - Redundant check if `udm_rid != next_rid` (in included in previous sid comparison) - UDM.create_user() without disabling (drs) replication (S4-connector is stopped at this point)
Reworked in r75526.