It would be very helpfull for admins, if the migration script would copy some more LDAP attributes than it's currently done (last tested with beta2). Many admins have attributes are like sn, givenName, mail, unixHomeDirectory... already in their s3 LDAP. After the migration to s4, these are all lost and have to be added by hand again, what is very much work. Also if s3 was configured with roaming profiles, all accounts have to be reconfigured using the AD user/group console to add the path to the userprofiles again. It would be good if the s3 LDAP attribute profilePath would also be migrated if present. If roaming profiles where configured globally (not per user), then maybe the attribute can be filled (for users where it's empty) by the value of "logon path" from the old smb.conf. This would make the migration process much easier and less work. Thanks.
Yes, it would be a useful thing. Do you think you could work on a patch, if I gave you the framework? The profilePath should be being migrated already - it is accessed via the passdb interface, and we move all these attributes. What I propose to do is that when we are using ldap, that we use ldb to connect directly to the LDAP server using the secret from the samba3 secrets.tdb to access the ldap backend, bypassing passdb.
I really wish I could help, but I'm not very familiar with programming. The only thing I could offer is testing, give some requirements which will help admins for the migration in real live and maybe add some small stuff to the wiki (for things I had completely understand how they work in s4 :-)) About the profilePath: We have configured the profilePath globaly in smb.conf for s3 and not on a per user basis. Maybe, if the users attribute is empty, you could look, if it's set gobally in smb.conf and use this value.
Bugs 9836 is a duplicate of this.
Created attachment 9588 [details] Patch to include Netlogon path and script and also home dir.
Yes, to me this seems okay, one small more cosmetic oriented change: + /* sambaProfilePath -> ProfilePath */ + { + .local_name = "sambaProfilePath", + .type = LDB_MAP_RENAME, + .u = { + .rename = { + .remote_name = "ProfilePath", ^^^ use .remote_name = "profilePath" to match the correct attribute name + }, + }, + }, (In reply to comment #4) > Created attachment 9588 [details] > Patch to include Netlogon path and script and also home dir.
Are these patches tested? I'm pretty sure we don't use samba3sam in the upgrade process (we could, but I chose to instead base things on the passdb layer).
Created attachment 9591 [details] Patch to include Netlogon path and script and also home dir. I was thinking when will I make this silly mistake ;0 Thank. Updated.
What I would like very much, would be a way to specify 'mappings' for samba3 to samba4 ldap fields... That way, admins could copy/map whatever they need in their environment. samba-tool classicupgrade --mapfile=./mappings.ldap And mappings.ldap would be something like sAMAccountName = userPrincipalName cn = displayName That way, all attributes supported by the schemas could be transferred...
Unfortunately I'm no programmer, but since we're 'struggling' with exactly this right now, we could perhaps test and try out if that would help?
I have only analysed the contents of the patch. But I was not sure if we would still need samba3sam LDB module - but it is also some kind of wrapper for s3-s4? (In reply to comment #6) > Are these patches tested? I'm pretty sure we don't use samba3sam in the > upgrade process (we could, but I chose to instead base things on the passdb > layer).
(In reply to comment #6) > Are these patches tested? I'm pretty sure we don't use samba3sam in the > upgrade process (we could, but I chose to instead base things on the passdb > layer). If we are perform an classical upgrade using samba-tool samba-tool domain classicupgrade --dbdir=/var/lib/samba/samba3tdb/ --use-xattrs=yes --realm=headoffice.location1.company.com /var/lib/samba/samba3tdb/samba3.conf (In reply to comment #10) > I have only analysed the contents of the patch. But I was not sure if we would > still need samba3sam LDB module - but it is also some kind of wrapper for > s3-s4? > > (In reply to comment #6) > > Are these patches tested? I'm pretty sure we don't use samba3sam in the > > upgrade process (we could, but I chose to instead base things on the passdb > > layer). Did we have any new way of doing it? This patch also don't help if we already migrated to the AD and going to migrate the changes again.
I've tested the change when patch back to 4.1.3. But not sure about the latest git version. It is working right as expected. Thank You
(In reply to comment #6) > Are these patches tested? I'm pretty sure we don't use samba3sam in the > upgrade process (we could, but I chose to instead base things on the passdb > layer). The name parameter from LDAP are not copy. At least from what I tested. givenName sn mail are not copy over. But the netlogon path and etc are ok. Any advise on that? Thank you.
Andrew, what should we do here? I think that the argumentation is valid.
Created attachment 9607 [details] Patch to include Netlogon path and script and also home dir. Remove sn, givenname and mail which is not working. Please help to commit to main brunch :) Thank You.
(In reply to comment #15) > Created attachment 9607 [details] > Patch to include Netlogon path and script and also home dir. > > Remove sn, givenname and mail which is not working. > > Please help to commit to main brunch :) > > Thank You. I still don't see how this patch works. Can you show me some proof of there being any change with or without this patch? This module is not used by the classicupgrade code as far as I understand it. We also really need to work out a way to test this stuff in 'make test', either by invoking slapd (if found on the test system) or starting samba's own LDAP server contorted into looking like a generic LDAP server. We have had too many untested patches in this area (many of which I've been involved with).
Dear Andrew, Any suggestion on how can I proof that? Sending th ldif on after the patch? Thank you
(In reply to comment #17) > Dear Andrew, > > Any suggestion on how can I proof that? > > Sending th ldif on after the patch? > > Thank you Yes, that would be a good way to demonstrate the issue and how this fixes it.
Created attachment 9614 [details] LDAP Ldif LDAP ldif (userpassword removed)
Created attachment 9615 [details] AD ldif AD Ldif
(In reply to comment #20) > Created attachment 9615 [details] > AD ldif > > AD Ldif And what do you get if you don't use your patch? Ie, what is the impact on the AD LDIF of using or not using your patch?
Created attachment 9617 [details] AD_no patch ldif Strange. Even without the patch homeDirectory homeDrive profilePath scriptPath are all ok... I'm puzzle now... Did we have this bugs before? Was it fixed from 4.1.2 --> 4.1.3?
Exactly. A number of attributes are already copied, because they are handled by our passdb layer which is what we built the classicupgrade script around. There are however other attributes which are not currently handled. We certainly can do more here, it is just that this approach is not the right one, unless we actually change our code to use samba3sam!