[cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation

Kamen Mazdrashki kamen.mazdrashki at postpath.com
Mon Oct 26 15:41:10 MDT 2009


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/20091026/9f9a8519/attachment-0001.html>


More information about the cifs-protocol mailing list