Bug 9008 - Copy additional LDAP attributes on migration
Summary: Copy additional LDAP attributes on migration
Status: ASSIGNED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Tools (show other bugs)
Version: unspecified
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-26 19:46 UTC by Marc Muehlfeld
Modified: 2016-12-09 16:37 UTC (History)
7 users (show)

See Also:


Attachments
Patch to include Netlogon path and script and also home dir. (2.20 KB, patch)
2014-01-13 20:23 UTC, Chan Min Wai
no flags Details
Patch to include Netlogon path and script and also home dir. (2.20 KB, patch)
2014-01-14 05:04 UTC, Chan Min Wai
no flags Details
Patch to include Netlogon path and script and also home dir. (1.76 KB, patch)
2014-01-21 14:59 UTC, Chan Min Wai
no flags Details
LDAP Ldif (1.15 KB, text/plain)
2014-01-24 16:45 UTC, Chan Min Wai
no flags Details
AD ldif (1.18 KB, text/plain)
2014-01-24 16:45 UTC, Chan Min Wai
no flags Details
AD_no patch ldif (1.17 KB, text/plain)
2014-01-25 17:41 UTC, Chan Min Wai
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2012-06-26 19:46:31 UTC
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.
Comment 1 Andrew Bartlett 2012-06-27 08:35:52 UTC
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.
Comment 2 Marc Muehlfeld 2012-06-27 14:47:49 UTC
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.
Comment 3 Chan Min Wai 2014-01-13 20:22:32 UTC
Bugs 9836 is a duplicate of this.
Comment 4 Chan Min Wai 2014-01-13 20:23:55 UTC
Created attachment 9588 [details]
Patch to include Netlogon path and script and also home dir.
Comment 5 Matthias Dieter Wallnöfer 2014-01-13 21:15:04 UTC
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.
Comment 6 Andrew Bartlett 2014-01-13 21:42:32 UTC
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).
Comment 7 Chan Min Wai 2014-01-14 05:04:53 UTC
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.
Comment 8 heupink 2014-01-14 08:19:15 UTC
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...
Comment 9 heupink 2014-01-14 09:23:09 UTC
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?
Comment 10 Matthias Dieter Wallnöfer 2014-01-14 10:15:35 UTC
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).
Comment 11 Chan Min Wai 2014-01-14 20:07:11 UTC
(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.
Comment 12 Chan Min Wai 2014-01-14 20:12:36 UTC
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
Comment 13 Chan Min Wai 2014-01-16 16:53:38 UTC
(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.
Comment 14 Matthias Dieter Wallnöfer 2014-01-21 10:53:30 UTC
Andrew, what should we do here? I think that the argumentation is valid.
Comment 15 Chan Min Wai 2014-01-21 14:59:42 UTC
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.
Comment 16 Andrew Bartlett 2014-01-23 02:49:43 UTC
(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).
Comment 17 Chan Min Wai 2014-01-23 07:30:26 UTC
Dear  Andrew,

Any suggestion on how can I proof that?

Sending th ldif on after the patch?

Thank you
Comment 18 Andrew Bartlett 2014-01-23 07:43:57 UTC
(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.
Comment 19 Chan Min Wai 2014-01-24 16:45:08 UTC
Created attachment 9614 [details]
LDAP Ldif

LDAP ldif (userpassword removed)
Comment 20 Chan Min Wai 2014-01-24 16:45:37 UTC
Created attachment 9615 [details]
AD ldif

AD Ldif
Comment 21 Andrew Bartlett 2014-01-24 18:42:11 UTC
(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?
Comment 22 Chan Min Wai 2014-01-25 17:41:49 UTC
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?
Comment 23 Andrew Bartlett 2014-01-31 03:51:33 UTC
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!