|
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@...
http://repo.or.cz/w/Samba/kamenim.git-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/ _______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Hi Kamen:
Thank you for contacting Microsoft regarding your question about MS-DRSR. A member of Protocol Documentation Team will be in touch soon.
Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft
-----Original Message-----
From: Kamen Mazdrashki [mailto: kamen.mazdrashki@...]
Sent: Tuesday, October 20, 2009 8:36 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: 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@...]
Sent: Tuesday, October 20, 2009 9:36 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
 Re: 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@...
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@...]
> Sent: Wednesday, October 21, 2009 7:37 PM
> To: Kamen Mazdrashki; Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...]
> Sent: Tuesday, October 20, 2009 9:36 AM
> To: Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...
> http://repo.or.cz/w/Samba/kamenim.git> -------------------------------------
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: 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@...]
Sent: Thursday, October 22, 2009 4:16 AM
To: Bill Wesse; Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Wednesday, October 21, 2009 7:37 PM
> To: Kamen Mazdrashki; Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...]
> Sent: Tuesday, October 20, 2009 9:36 AM
> To: Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...
> http://repo.or.cz/w/Samba/kamenim.git> -------------------------------------
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: 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@...; cifs-protocol@...
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@...]
Sent: Thursday, October 22, 2009 4:16 AM
To: Bill Wesse; Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Wednesday, October 21, 2009 7:37 PM
> To: Kamen Mazdrashki; Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...]
> Sent: Tuesday, October 20, 2009 9:36 AM
> To: Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...
> http://repo.or.cz/w/Samba/kamenim.git> -------------------------------------
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: 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@...
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@...]
> Sent: Thursday, October 22, 2009 5:50 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 4:16 AM
> To: Bill Wesse; Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Wednesday, October 21, 2009 7:37 PM
> > To: Kamen Mazdrashki; Interoperability Documentation Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...]
> > Sent: Tuesday, October 20, 2009 9:36 AM
> > To: Interoperability Documentation Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > http://repo.or.cz/w/Samba/kamenim.git> > -------------------------------------
> > CISCO SYSTEMS BULGARIA EOOD
> > http://www.cisco.com/global/BG/> >
>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: 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@...]
Sent: Thursday, October 22, 2009 10:56 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Thursday, October 22, 2009 5:50 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 4:16 AM
> To: Bill Wesse; Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Wednesday, October 21, 2009 7:37 PM
> > To: Kamen Mazdrashki; Interoperability Documentation Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...]
> > Sent: Tuesday, October 20, 2009 9:36 AM
> > To: Interoperability Documentation Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > http://repo.or.cz/w/Samba/kamenim.git> > -------------------------------------
> > CISCO SYSTEMS BULGARIA EOOD
> > http://www.cisco.com/global/BG/> >
>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: 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@...; cifs-protocol@...
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@...]
Sent: Thursday, October 22, 2009 10:56 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Thursday, October 22, 2009 5:50 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 4:16 AM
> To: Bill Wesse; Interoperability Documentation Help
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Wednesday, October 21, 2009 7:37 PM
> > To: Kamen Mazdrashki; Interoperability Documentation Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...]
> > Sent: Tuesday, October 20, 2009 9:36 AM
> > To: Interoperability Documentation Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > http://repo.or.cz/w/Samba/kamenim.git> > -------------------------------------
> > CISCO SYSTEMS BULGARIA EOOD
> > http://www.cisco.com/global/BG/> >
>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Thank you very much!
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...; cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...; cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Good evening Bill,
Thanks for the update.
BR,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 J
Regards,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Monday, October 26, 2009 5:41 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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 J
Regards,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse [mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 5:41 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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 J
Regards,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Tuesday, October 27, 2009 7:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 5:41 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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 J
Regards,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse [mailto:billwe@...]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...]
Sent: Tuesday, October 27, 2009 5:54 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Tuesday, October 27, 2009 7:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 5:41 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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 J
Regards,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
|
Re: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Bill,
I am truly surprised you can’t
reproduce the strange behavior during Win-to-Win replication.
Please, let me know if I can
help you with running Samba’s tests?
Basically, after building Samba,
you just need to execute:
bin/smbtorture
-Uadministrator%333 --configfile=/usr/local/samba/etc/drsuapi.conf
ncacn_ip_tcp:10.191.10.229[print,seal] RPC-DSSYNC --option="dssync:highest_usn=24608"
-d1 > RPC-DSSYNC-w2k8.log
I am sending you the conf file
here again, so you could have it at hand.
Thanks,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, November 02, 2009 7:15 PM
To: Kamen Mazdrashki
Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 -
prefixMap implementation
I have completed the debug, and
find that the attid’s are being constructed per the algorithm (and per the
entries in the prefixMap table). I cannot account for your results using just
R2 (which is using DRS_MSG_GETCHGREPLY_V7, no surprise here). Hence, I am
setting up to run the tests again using smbtorture. It may take me a few days
to build & stabilize that, as I have not had previous occasion to use the
torture tests.
Very strange!
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: Friday, October 30, 2009 12:08 PM
To: 'Kamen Mazdrashki'
Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap
implementation
Glad to hear your efforts are
going well.
I did my testing on 2008 R2
(release build 6.1.7600); after some nasty snags (involving, ugh, hardware
problems), I am now working through the replication data on both DC partners.
Hopefully the mysterious values
are artifacts of the beta (if that is what you are using), or some surprise in
struct versioning (I haven’t gotten near this yet).
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@...]
Sent: Friday, October 30, 2009 4:52 AM
To: Bill Wesse
Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 -
prefixMap implementation
No worries,
I’ve finished my implementation
and I will test it in following few days.
I think the part with
OID-to-ATTID/ATTID-to-OID is well encapsulated, so I just have put what are to
find out about Win2k8 behavior.
Thanks again for your efforts.
BR,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Thursday, October 29, 2009 3:34 PM
To: Kamen Mazdrashki
Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 -
prefixMap implementation
I’ve run into several snags on the
debug, and may have to rebuild my Hyper-V host (I hope not). Sorry for the
delay.
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: Wednesday, October 28, 2009 11:28 AM
To: 'Kamen Mazdrashki'
Cc: pfif@...; cifs-protocol@...
Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 -
prefixMap implementation
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@...]
Sent: Tuesday, October 27, 2009 5:54 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Tuesday, October 27, 2009 7:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 5:41 PM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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 J
Regards,
Kamen Mazdrashki
kamen.mazdrashki@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 7:31 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Monday, October 26, 2009 11:06 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
From: Bill Wesse
[mailto:billwe@...]
Sent: Monday, October 26, 2009 4:56 PM
To: Kamen Mazdrashki
Cc: pfif@...; cifs-protocol@...
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@...]
Sent: Friday, October 23, 2009 8:32 AM
To: Bill Wesse
Cc: pfif@...; cifs-protocol@...
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@...
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@...]
> Sent: Friday, October 23, 2009 2:44 PM
> To: Kamen Mazdrashki
> Cc: pfif@...; cifs-protocol@...
> 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@...; cifs-protocol@...
> 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@...]
> Sent: Thursday, October 22, 2009 10:56 AM
> To: Bill Wesse
> Cc: pfif@...; cifs-protocol@...
> 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@...
> 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@...]
> > Sent: Thursday, October 22, 2009 5:50 PM
> > To: Kamen Mazdrashki
> > Cc: pfif@...; cifs-protocol@...
> > 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@...; cifs-protocol@...
> > 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@...]
> > Sent: Thursday, October 22, 2009 4:16 AM
> > To: Bill Wesse; Interoperability Documentation
Help
> > Cc: pfif@...; cifs-protocol@...
> > 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@...
> > 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@...]
> > > Sent: Wednesday, October 21, 2009 7:37 PM
> > > To: Kamen Mazdrashki; Interoperability
Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...]
> > > Sent: Tuesday, October 20, 2009 9:36 AM
> > > To: Interoperability Documentation Help
> > > Cc: pfif@...;
cifs-protocol@...
> > > 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@...
> > > http://repo.or.cz/w/Samba/kamenim.git
> > > -------------------------------------
> > > CISCO SYSTEMS BULGARIA EOOD
> > > http://www.cisco.com/global/BG/
> > >
> >
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol
|
RPC-DSSYNC-w2k3.log.doc (180K) Download Attachment
