Bug 2182 - Net rpc vampire does'nt keep sambaMangedDial in sync
Summary: Net rpc vampire does'nt keep sambaMangedDial in sync
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: net utility (show other bugs)
Version: 3.0.10
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Guenther Deschner
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-22 01:09 UTC by Yohann Fourteau
Modified: 2005-08-24 10:24 UTC (History)
0 users

See Also:


Attachments
base64-encode munged dial (638 bytes, patch)
2004-12-22 03:27 UTC, Guenther Deschner
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yohann Fourteau 2004-12-22 01:11:26 UTC
I use net rpc vampire to migrate a NT domain to a Samba domain (with LDAP
backend).

The user TSE data stored in the SAM are not migrated. There is no
sambaMangedDial attribute in user entries after the net rpc vampire.
Comment 1 Guenther Deschner 2004-12-22 02:33:12 UTC
This was fixed in subversion some days ago (See
http://build.samba.org/build.pl?function=diff;tree=samba_3_0;date=1102671903;author=gd;revision=4127
for the patch). 

Could you give that a try and reopen the bug if you find any problems with it?

Thanks for your report.
Comment 2 Yohann Fourteau 2004-12-22 03:12:59 UTC
It doesn't work

Normaly, in LDAP the attribute is stored in base64 format. With the new net rpc
vampire, it's stored in raw format.
You just have to convert the value into base64 format.


Comment 3 Guenther Deschner 2004-12-22 03:27:36 UTC
Created attachment 861 [details]
base64-encode munged dial
Comment 4 Guenther Deschner 2004-12-22 03:28:28 UTC
I've updated an updated version of the patch. Please give us feedback again.
Thanks for testing.
Comment 5 Yohann Fourteau 2004-12-22 06:43:19 UTC
It's now ok for the base64 format. But there is a problem : the attribute is
truncated.

With your code I have  (with a lot of special car) :
                                               
CtxCfgPresent551e0bbCtxCfgFlags100e0001CtxCallback0000000CtxShadow01000000
CtxMaxConnectionTime00000000CtxMaxDisconnectionTime0000000CtxMaxIdleTime
00000000CtxKeyboardLayout0

And it must be (with a lot of special car) :

                                               
CtxCfgPresent551e0bbCtxCfgFlags100e0001CtxCallback0000000CtxShadow01000000
CtxMaxConnectionTime00000000CtxMaxDisconnectionTime0000000CtxMaxIdleTime
00000000CtxKeyboardLayout00000000*CtxMinEncryptionLevel00 CtxWorkDirectory
00 CtxNWLogonServer00CtxWFHomeDir00"CtxWFHomeDirDrive00 CtxWFProfilePath
5c5c746f746f5c7461746100"CtxInitialProgram00"CtxCallbackNumber00

Comment 6 Yohann Fourteau 2004-12-22 10:00:22 UTC
With the first patch, it's not in base64 but there is the whole string in the
attribute.
With the second patch, it's in base64 but the attribute is truncated.

The problem comes with the base64 conversion.
Comment 7 Yohann Fourteau 2004-12-22 10:32:13 UTC
It's :
mung.length = 2*delta->uni_parameters.uni_str_len;

and not 
mung.length = delta->uni_parameters.uni_str_len;


delta->uni_parameters.buffer is uint16 and you cast it into uint8
(I'm not sure it's the real reason, but it works now :)
Comment 8 Guenther Deschner 2004-12-26 04:40:47 UTC
Fixed in Subversion (this time hopefully correct :).

Please reopen if you see any further problems.
Comment 9 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:24:46 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.