[cifs-protocol] Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Bill Wesse
billwe at microsoft.com
Wed Oct 28 09:28:25 MDT 2009
I appreciate your comments – I will update you later today or tomorrow AM with my results.
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
Sent: Tuesday, October 27, 2009 5:54 PM
To: Bill Wesse
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Hi Bill,
Thanks a lot for your efforts.
I am crossing my fingers for you to not have hard time finding what the issue might be.
Regards,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse [mailto:billwe at microsoft.com]
Sent: Tuesday, October 27, 2009 7:56 PM
To: Kamen Mazdrashki
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Good afternoon Kamen – I have again reviewed the prefixMap code, and tested replication between 2 2008R2 DC’s (VMs). The replication succeeded, and I am setting up for a debug of the prefixMap code & replication endpoints.
I hope to finish that tomorrow (each run will require me to restore my virtual hard disks, so it may take several tries before I validate both ends of the replication).
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
From: Bill Wesse
Sent: Tuesday, October 27, 2009 6:25 AM
To: 'Kamen Mazdrashki'
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Thanks – I wanted to be as complete as possible. I am currently setting up several R2 VM’s to duplicate the problem. There shouldn’t be anything different about ATTID en/decoding, from what I see in the code (I must have missed something – which is what I intend to find out today).
I will keep you updated!
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
Sent: Monday, October 26, 2009 5:41 PM
To: Bill Wesse
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Hi Bill,
Wow, it seem you have made quite a test tool for prefixMap.
And to answer your question – I am doing replication from Win2k8-R2.
Yes, you are right about the last three lines in make_attid() implementation. I just needed low-word of ATTID as I haven’t implemented full prefixMap functionality – i.e. there is no prefixMap at all.
So I used this script to encode/decode values in the log file “one the fly” – just a quick conversion.
I found Python to be quite handy in this – just open Python console and use those helper functions quickly.
Frankly said, I didn’t expected to have any problems with encoding/decoding ATTIDs – given the fact you have released such a detailed description of the algorithm used.
ATTIDs you have made using your tool are quite correct. Except that Win2k8 doesn’t behave that way.
I am really expecting that MS dev team have made little bit different implementation in Win2k8 for some reason.
Quite curious what the reason may be though ☺
Regards,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse [mailto:billwe at microsoft.com]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
This is more than interesting. I have verified that the drsuapi_DsReplicaAttribute.attid values from the RPC-DSSYNC-w2k8.log.doc file are definitely wrong. Neither the upperWord or lowerWord values are what they should be in the Win2k8 log.
One important question: are you replicating to 2008R2, or from it (if from, there is something drastically wrong with R2, and I will need to get this in front of both our document & product development teams).
I have verified the correct values are generated for MakeAttid() and OidFromAttid(), using C# code (see attachment + below info on PrefixMapper).
PrefixTable.cs: public Oid OidFromAttid(UInt32 AttrTyp,…)
Oid.cs: the following is called from the Oid constructor (public Oid(String stringOid))
private Byte[ ] StringOidToBytes(String Text, out int PrefixLength, out UInt16 LastSubID)
(MakeAttid occurs in PrefixTable.Instance.Add(…))
I am not very good with Python; however, the last three lines of make_attid(oid) (prefixmap.py) don’t seem right to me:
upperWord = 'prefixIndex'
attid = '%04X' % lowerWord # attr := upperWord * 65536 + lowerWord
return (oidPrefix, attid)
Here is what should be in RPC-DSSYNC-w2k8.log.doc:
attid: 0x8933929C -> should be 0x48230001
id_prefix: 0x00004823
bin_oid: 0x2A817A + 01 ('1.2.250.1')
attid_loword: 0x0001
attid: 0x87159F45 -> should be 0x48230082
id_prefix: 0x00004823
bid_oid: 0x2A817A + 8102 ('1.2.250.130')
attid_loword: 0x0082
attid: 0x85C6D3B9 -> should be 0x0DC78002
id_prefix: 0x00000DC7
bin_oid: 0x2A817A81 + 8002 ('1.2.250.16386')
attid_loword: 0x8002
attid: 0x9E0386A9 -> should be 0x3C608002
id_prefix: 0x00003C60
bin_oid: 0x2A817A8180 + 8002 ('1.2.250.2097154')
attid_loword: 0x8002
PrefixMapper is a console program (no command arguments; a Visual Studio 2008 project). Sample output is below.
PrefixTable (Initial)
---------------------
Index prefixIndex prefixString
----- ----------- ------------------------------------
[0] 0x00000000 55 04
[1] 0x00000001 55 06
[2] 0x00000002 2A 86 48 86 F7 14 01 02
[3] 0x00000003 2A 86 48 86 F7 14 01 03
[4] 0x00000004 60 86 48 01 65 02 02 01
[5] 0x00000005 60 86 48 01 65 02 02 03
[6] 0x00000006 60 86 48 01 65 02 01 05
[7] 0x00000007 60 86 48 01 65 02 01 04
[8] 0x00000008 55 05
[9] 0x00000009 2A 86 48 86 F7 14 01 04
[10] 0x0000000A 2A 86 48 86 F7 14 01 05
[11] 0x00000013 09 92 26 89 93 F2 2C 64
[12] 0x00000014 60 86 48 01 86 F8 42 03
[13] 0x00000015 09 92 26 89 93 F2 2C 64 01
[14] 0x00000016 60 86 48 01 86 F8 42 03 01
[15] 0x00000017 2A 86 48 86 F7 14 01 05 B6 58
[16] 0x00000018 55 15
[17] 0x00000019 55 12
[18] 0x0000001A 55 14
Oids
----
Added: 1.2.250.1
Construction: StringOid
Value: 1.2.250.1
Binary: 2A 81 7A 01
Prefix: 2A 81 7A
Postfix: 01
Description: 0x2A817A + 01 ('1.2.250.1')
PrefixLen: 3
PrefixIndex: 0x677D
LastSubID: 0x0001
AttId: 0x677D0001
Found: 1.2.250.130
Construction: StringOid
Value: 1.2.250.130
Binary: 2A 81 7A 81 02
Prefix: 2A 81 7A
Postfix: 81 02
Description: 0x2A817A + 8102 ('1.2.250.130')
PrefixLen: 3
PrefixIndex: 0x677D
LastSubID: 0x0082
AttId: 0x677D0082
Added: 1.2.250.16386
Construction: StringOid
Value: 1.2.250.16386
Binary: 2A 81 7A 81 80 02
Prefix: 2A 81 7A 81
Postfix: 80 02
Description: 0x2A817A81 + 8002 ('1.2.250.16386')
PrefixLen: 4
PrefixIndex: 0x68C3
LastSubID: 0x8002
AttId: 0x68C38002
Added: 1.2.250.2097154
Construction: StringOid
Value: 1.2.250.2097154
Binary: 2A 81 7A 81 80 80 02
Prefix: 2A 81 7A 81 80
Postfix: 80 02
Description: 0x2A817A8180 + 8002 ('1.2.250.2097154')
PrefixLen: 5
PrefixIndex: 0x49D1
LastSubID: 0x8002
AttId: 0x49D18002
PrefixTable (Final)
-------------------
Index prefixIndex prefixString
----- ----------- ------------------------------------
[0] 0x00000000 55 04
[1] 0x00000001 55 06
[2] 0x00000002 2A 86 48 86 F7 14 01 02
[3] 0x00000003 2A 86 48 86 F7 14 01 03
[4] 0x00000004 60 86 48 01 65 02 02 01
[5] 0x00000005 60 86 48 01 65 02 02 03
[6] 0x00000006 60 86 48 01 65 02 01 05
[7] 0x00000007 60 86 48 01 65 02 01 04
[8] 0x00000008 55 05
[9] 0x00000009 2A 86 48 86 F7 14 01 04
[10] 0x0000000A 2A 86 48 86 F7 14 01 05
[11] 0x00000013 09 92 26 89 93 F2 2C 64
[12] 0x00000014 60 86 48 01 86 F8 42 03
[13] 0x00000015 09 92 26 89 93 F2 2C 64 01
[14] 0x00000016 60 86 48 01 86 F8 42 03 01
[15] 0x00000017 2A 86 48 86 F7 14 01 05 B6 58
[16] 0x00000018 55 15
[17] 0x00000019 55 12
[18] 0x0000001A 55 14
[19] 0x0000677D 2A 81 7A
[20] 0x000068C3 2A 81 7A 81
[21] 0x000049D1 2A 81 7A 81 80
Oids from String and Binary Comparison Checks
---------------------------------------------
Oid[0] Match
Found: 1.2.250.1
Oid[1] Match
Found: 1.2.250.130
Oid[2] Match
Found: 1.2.250.16386
Oid[3] Match
Found: 1.2.250.2097154
PrefixTable Search
------------------
Found Oid[0] at [19] (Match)
===============================
Index prefixIndex prefixString
----- ----------- ------------------------------------
[19] 0x0000677D 2A 81 7A
Construction: StringOid
Value: 1.2.250.1
Binary: 2A 81 7A 01
Prefix: 2A 81 7A
Postfix: 01
Description: 0x2A817A + 01 ('1.2.250.1')
PrefixLen: 3
PrefixIndex: 0x677D
LastSubID: 0x0001
AttId: 0x677D0001
Found Oid[1] at [19] (Match)
===============================
Index prefixIndex prefixString
----- ----------- ------------------------------------
[19] 0x0000677D 2A 81 7A
Construction: StringOid
Value: 1.2.250.130
Binary: 2A 81 7A 81 02
Prefix: 2A 81 7A
Postfix: 81 02
Description: 0x2A817A + 8102 ('1.2.250.130')
PrefixLen: 3
PrefixIndex: 0x677D
LastSubID: 0x0082
AttId: 0x677D0082
Found Oid[2] at [20] (Match)
===============================
Index prefixIndex prefixString
----- ----------- ------------------------------------
[20] 0x000068C3 2A 81 7A 81
Construction: StringOid
Value: 1.2.250.16386
Binary: 2A 81 7A 81 80 02
Prefix: 2A 81 7A 81
Postfix: 80 02
Description: 0x2A817A81 + 8002 ('1.2.250.16386')
PrefixLen: 4
PrefixIndex: 0x68C3
LastSubID: 0x8002
AttId: 0x68C38002
Found Oid[3] at [21] (Match)
===============================
Index prefixIndex prefixString
----- ----------- ------------------------------------
[21] 0x000049D1 2A 81 7A 81 80
Construction: StringOid
Value: 1.2.250.2097154
Binary: 2A 81 7A 81 80 80 02
Prefix: 2A 81 7A 81 80
Postfix: 80 02
Description: 0x2A817A8180 + 8002 ('1.2.250.2097154')
PrefixLen: 5
PrefixIndex: 0x49D1
LastSubID: 0x8002
AttId: 0x49D18002
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Good evening Bill,
Thanks for the update.
BR,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse [mailto:billwe at microsoft.com]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Good morning Kamen – I am sending this update to advise you of my progress. I have coded the algorithms in C#, in advance of scanning the last data (ldif & py) you sent.
I expect to have some results for you by tomorrow morning at the latest (along with the Visual Studio project).
Thanks for your patience.
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Hi Bill,
Sorry, I must have missed the LDIF. Here it is.
I have also gathered some data for you - the log file is bloated with other information, so here is just the most important observations from the log.
Win2k8
-----------------------------------------------------------
attid: 0x8933929C
id_prefix: 0x00004823
bin_oid: 0x2A817A + 01 ('1.2.250.1')
attid_loword: 0x0001
attid: 0x87159F45
id_prefix: 0x00004823
bid_oid: 0x2A817A + 8102 ('1.2.250.130')
attid_loword: 0x0082
attid: 0x85C6D3B9
id_prefix: 0x00000DC7
bin_oid: 0x2A817A81 + 8002 ('1.2.250.16386')
attid_loword: 0x8002
attid: 0x9E0386A9
id_prefix: 0x00003C60
bin_oid: 0x2A817A8180 + 8002 ('1.2.250.2097154')
attid_loword: 0x8002
I have 4 attributes received – all grouped above.
For the first one I got ATTID: 0x8933929C
If we follow the logic in OidFromAttid(), then first we are to find a prefixMap entry with id_prefix: 0x0000008933
Well, there is no such entry (please look in log file for Win2k8).
prefixMap entry we should find for this ATTID is id_prefix: 0x00004823. So let’s pretend, that 0x8933 is somehow mapped to 0x4823 and try to make full binary-oid of the Attribute.
According to docs, I should add the lo-word for ATTID, e.g. 0x929C, to the partial binary-oid in the prefixMap - 0x2A817A.
When I do this, I got OID='1.2.250.4764' instead of '1.2.250.1'.
Btw, in order to not making all those calculations by hand every time, I’ve created a little Python script to do the job.
So, if you have a Python installed, you can just ‘import prefixmap’ in Python console and then execute prefixmap.oid_from_attid('0x2A817A', '0x8933929C') – it will return '1.2.250.4764'. Prefix map module implements algorithms described in MS-DRSR.
I am attaching the Python script also if you want to play with it.
Regards,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
> -----Original Message-----
> From: Bill Wesse [mailto:billwe at microsoft.com]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
> prefixMap implementation
>
> Good morning again Kamen. I have completed my investigation of our
> prefixMap, MakeAttid() and OidFromAttid() on Windows 2003 & 2008 R2:
> they are indeed functionally identical.
>
> So, something else is going on here, and we will need to duplicate your
> results under debug. To do that, I need to ask you to forward a copy of
> the LDIF file to me (I received the docs & conf file, but not the
> LDIF).
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
> -----Original Message-----
> From: Bill Wesse
> Sent: Thursday, October 22, 2009 11:15 AM
> To: 'Kamen Mazdrashki'
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
> prefixMap implementation
>
> Thanks for the advisory - I will follow up with you on the attid - I
> will be expanding my code study on this.
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
>
> -----Original Message-----
> From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
> prefixMap implementation
>
> Hi Bill,
>
> Currently this issue stops me from implementing MakeAttid() and
> OidFromAttid() to work transparently in all cases - from Win2k3 to
> Win2k8. Also I can't make a reasonable unit test for those functions.
> Nevertheless, it is not a 'show stopper' for me at this stage, as
> current implementation (following MS-DRSR) work well for Win2k3 and
> Win2k8 (without modifying schema).
>
> Attached you may find:
> - LDIF file;
> - 2 logs - from Win2k3 (Functional Level = Win 2000) and Win2k8-R2
> (Functional Level = Win 2008 R2);
> - smb conf file used for testing, in case you want to try it by
> yourself
>
> I am currently on making an resume for Win2k8 result I got from windows
> server.
>
> It seems not to be a corner case to me.
> It seems more like a special case for Win2k8 - ATTIDs for all newly
> created attributes are with 31-th bit set.
>
> Regards,
> Kamen Mazdrashki
> kamen.mazdrashki at postpath.com
> http://repo.or.cz/w/Samba/kamenim.git
> -------------------------------------
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/
>
>
> > -----Original Message-----
> > From: Bill Wesse [mailto:billwe at microsoft.com]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif at tridgell.net; cifs-protocol at samba.org
> > Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2
> -
> > prefixMap implementation
> >
> > Hello again, Kamen. Could you forward the LDIF file to me? I want to
> > make sure I haven't missed anything (thanks).
> >
> > Also, I have again reviewed the MakeAttid() and OidFromAttid() pseudo
> > code in [MS-DRSR] 5.16.4 (ATTRTYP-to-OID Conversion) - they do appear
> > to be accurate representations of our implementations; my earlier
> > comment about a 'corner-case' was an error, I got mixed up between
> > string & binary OIDs.
> >
> > There is certainly something else going on here, and I will continue
> > working on it.
> >
> > Regards,
> > Bill Wesse
> > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > 8055 Microsoft Way
> > Charlotte, NC 28273
> > TEL: +1(980) 776-8200
> > CELL: +1(704) 661-5438
> > FAX: +1(704) 665-9606
> >
> >
> > -----Original Message-----
> > From: Bill Wesse
> > Sent: Thursday, October 22, 2009 8:51 AM
> > To: 'Kamen Mazdrashki'
> > Cc: pfif at tridgell.net; cifs-protocol at samba.org
> > Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2
> -
> > prefixMap implementation
> >
> > You are very welcome. Could you advise me concerning how much this is
> > affecting your implementation development, so that I can set the TDI
> > priority appropriately?
> >
> > I have cross-compared the Windows 2003 and Windows 2008 R2
> > implementations of the MakeAttid() and OidFromAttid() functions;
> there
> > appear to be no functional changes.
> >
> > I suspect there is some corner-case not fully described in the attid
> > composition in MakeAttid (lastValue ≥ 16384).
> >
> > procedure MakeAttid(var t: PrefixTable, o: OID): ATTRTYP ...
> > /*compose the attid*/
> > lowerWord := lastValue mod 16384
> > if lastValue ≥ 16384 then
> > /*mark it so that it is known to not be the whole lastValue*/
> > lowerWord := lowerWord + 32768
> > endif
> >
> > Regards,
> > Bill Wesse
> > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > 8055 Microsoft Way
> > Charlotte, NC 28273
> > TEL: +1(980) 776-8200
> > CELL: +1(704) 661-5438
> > FAX: +1(704) 665-9606
> >
> > -----Original Message-----
> > From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation Help
> > Cc: pfif at tridgell.net; cifs-protocol at samba.org
> > Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2
> -
> > prefixMap implementation
> >
> > Hi Bill,
> >
> > Thanks for your support.
> > I am looking forward to hearing from you soon.
> >
> > Regards,
> > Kamen Mazdrashki
> > kamen.mazdrashki at postpath.com
> > http://repo.or.cz/w/Samba/kamenim.git
> > -------------------------------------
> > CISCO SYSTEMS BULGARIA EOOD
> > http://www.cisco.com/global/BG/
> >
> >
> > > -----Original Message-----
> > > From: Bill Wesse [mailto:billwe at microsoft.com]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability Documentation Help
> > > Cc: pfif at tridgell.net; cifs-protocol at samba.org
> > > Subject: RE: [cifs-protocol] Question about [MS-DRSR] section
> 5.12.2
> > -
> > > prefixMap implementation
> > >
> > > Good afternoon Kamen. This is Bill Wesse from the Protocol Support
> > > team. I will be your contact for the case noted below, where you
> > asked
> > > about prefixMap implementation differences for Windows 2003 and
> > Windows
> > > 2008 R2.
> > >
> > > SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
> > >
> > > I will keep you updated with the results of my investigation as
> > details
> > > develop.
> > >
> > > Regards,
> > > Bill Wesse
> > > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > > 8055 Microsoft Way
> > > Charlotte, NC 28273
> > > TEL: +1(980) 776-8200
> > > CELL: +1(704) 661-5438
> > > FAX: +1(704) 665-9606
> > >
> > > -----Original Message-----
> > > From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif at tridgell.net; cifs-protocol at samba.org
> > > Subject: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
> > > prefixMap implementation
> > >
> > > Hi,
> > >
> > > I need a clarification about what are the differences between
> > prefixMap
> > > implementation for Win2K3 and Win2K8(R2).
> > >
> > > Attached you may find:
> > > 1. LDIF file to provision AD Schema with some test Attributes -
> OIDs
> > of
> > > those attributes are crafted so that different scenarios could be
> > > tested.
> > > 2. Log files gathered during execution of Samba's RPC-DSSYNC test
> > > against Win2K3 and Win2K8. I am sending the log files as Word
> > documents
> > > so it is easy for me to highlight interesting parts from the log
> > files.
> > > -- prefixMap received is highlighted with 'gray'; newly added
> > entries
> > > are highlighted with 'yellow'
> > > -- newly added object attributes received are also highlighted
> > > with 'yellow'
> > > 3. For testing I was using:
> > > -- Win2k3 R2 - Domain functional level = Win 2000 installation
> > > -- Win2K8 R2 - Domain functional lever = Win 2008 R2
> > > -- Samba 4 - latest build. Test run is RPC-DSSYNC.
> > > Command line for testing:
> > > $> bin/smbtorture -Uadministrator%333 --
> > > configfile=/usr/local/samba/etc/drsuapi.conf
> > > ncacn_ip_tcp:Win_machine_ip[print,seal] RPC-DSSYNC -d1
> > >
> > > As you may see, for Win2K3 everything works correctly as described
> > > in MS-DRSR, section 5.12.2.
> > > I.e. attribute with attid=0x1B860001 matches prefixMap entry with
> > > id=0x00001b86 and thus Attribute OID is correctly decoded as being
> > > '1.2.250.1'
> > >
> > > In Win2k8 log file however, for attid=0x85C6D3B9 matching prefixMap
> > > entry should be id=0x00004823 and it is not quite obvious how
> > > 0x85C6D3B9 is matched to 0x00004823?
> > >
> > > Please, clarify what is the algorithm used under Win2k8 for
> > MakeAttid()
> > > and OidFromAttid() functions?
> > >
> > > Many thanks in advance.
> > >
> > > Regards,
> > > Kamen Mazdrashki
> > > kamen.mazdrashki at postpath.com
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091028/1a77a983/attachment-0001.html>
More information about the cifs-protocol
mailing list