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

2009-10-22 Thread Kamen Mazdrashki 
Hi Bill,

Thanks for your support.
I am looking forward to hearing from you soon.

Regards,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/


> -Original Message-
> From: Bill Wesse [mailto:bil...@microsoft.com]
> Sent: Wednesday, October 21, 2009 7:37 PM
> To: Kamen Mazdrashki; Interoperability Documentation Help
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
> prefixMap implementation
> 
> Good afternoon Kamen. This is Bill Wesse from the Protocol Support
> team. I will be your contact for the case noted below, where you asked
> about prefixMap implementation differences for Windows 2003 and Windows
> 2008 R2.
> 
> SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation
> 
> I will keep you updated with the results of my investigation as details
> develop.
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL:  +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX:  +1(704) 665-9606
> 
> -Original Message-
> From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com]
> Sent: Tuesday, October 20, 2009 9:36 AM
> To: Interoperability Documentation Help
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
> prefixMap implementation
> 
> Hi,
> 
> I need a clarification about what are the differences between prefixMap
> implementation for Win2K3 and Win2K8(R2).
> 
> Attached you may find:
> 1. LDIF file to provision AD Schema with some test Attributes - OIDs of
> those attributes are crafted so that different scenarios could be
> tested.
> 2. Log files gathered during execution of Samba's RPC-DSSYNC test
> against Win2K3 and Win2K8. I am sending the log files as Word documents
> so it is easy for me to highlight interesting parts from the log files.
>   -- prefixMap received is highlighted with 'gray'; newly added entries
> are highlighted with 'yellow'
>   -- newly added object attributes received are also highlighted with
> 'yellow'
> 3. For testing I was using:
>   -- Win2k3 R2 - Domain functional level = Win 2000 installation
>   -- Win2K8 R2 - Domain functional lever = Win 2008 R2
>   -- Samba 4 - latest build. Test run is RPC-DSSYNC.
>  Command line for testing:
>  $> bin/smbtorture -Uadministrator%333 --
> configfile=/usr/local/samba/etc/drsuapi.conf
> ncacn_ip_tcp:Win_machine_ip[print,seal] RPC-DSSYNC -d1
> 
> As you may see, for Win2K3 everything works correctly as described in
> MS-DRSR, section 5.12.2.
> I.e. attribute with attid=0x1B860001 matches prefixMap entry with
> id=0x1b86 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=0x4823 and it is not quite obvious how
> 0x85C6D3B9 is matched to 0x4823?
> 
> Please, clarify what is the algorithm used under Win2k8 for MakeAttid()
> and OidFromAttid() functions?
> 
> Many thanks in advance.
> 
> Regards,
> Kamen Mazdrashki
> kamen.mazdras...@postpath.com
> http://repo.or.cz/w/Samba/kamenim.git
> -
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/
> 

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] DRS option bits

2009-10-23 Thread Kamen Mazdrashki 
Hi Hongwei,

What is this MS-DRDM document for?
Is it something to be released in near future or we can downloaded it right now?

Thanks,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/


> -Original Message-
> From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-
> boun...@cifs.org] On Behalf Of Hongwei Sun
> Sent: Friday, October 23, 2009 1:09 AM
> To: tri...@samba.org
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: Re: [cifs-protocol] DRS option bits
> 
> Tridge,
> 
>After a further review, we identified two more bits that could be
> observed on wire.
> 
>DRS_INIT_SYNC_NOW  0x0080
>DRS_PREEMPTED  0x0100
> 
>A description of these two bits and the DRSUAPI_DRS_NEVER_SYNCED bit
> you mentioned is shown as below.
> 
>   NSY (DRS_NEVER_SYNCED): There is no successfully completed
> replication from this source server.
>   ISN (DRS_INIT_SYNC_NOW): Perform initial replication now.
>   PE (DRS_PREEMPTED): Replication attempt is preempted by a higher
> priority replication request.
> 
>The information above has been added to 5.39 of MS-DRSR and 5.29 of
> MS-DRDM. The position of DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING bit in
> bit table has also been corrected.  The changes will appear in the
> future release of the documents.
> 
>The documentation team also confirmed that it is possible that the
> section numbers will change when any new content is added to MS-DRSR
> and MS-DRDM in the future. Section titles would probably work much
> better than section numbers.
> 
>If you have any more questions regarding this issue, please let us
> know.
> 
> 
> Thanks!
> 
> Hongwei
> 
> 
> 
> -Original Message-
> From: Hongwei Sun
> Sent: Tuesday, October 13, 2009 4:49 PM
> To: 'tri...@samba.org'; Interoperability Documentation Help
> Cc: cifs-proto...@samba.org; p...@tridgell.net
> Subject: RE: DRS option bits
> 
> Tridge,
> 
>I checked the definitions of these bit fields ,comparing with the
> MS-DRSR document.  The following is what I found.
> 
>1.  0x0020 is  DRSUAPI_DRS_NEVER_SYNCED , which means that sync
> is never completed successfully.  This bit is observed on wire, but not
> defined in the bit table in 5.39 DRS_OPTIONS.   I will file a request
> to add this bit to the document.
> 
>2. DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING should be  0x0040,
> instead of 0x0080 as indicated in your definition as well as the
> bit table. Bit SS should be in bit field #22.   I will also file a
> request to get this corrected in the document.
> 
>3.  There is one field defined in the bit table in the document but
> it is not shown in your definition. Please check it.
> 
>   DRSUAPI_DRS_SYNC_URGENT= 0x0008 (Bit SU
> field #19)
> 
>I will also forward your question regarding the numbering of the
> sections to the documentation team.  I will let you know their
> response.
> 
> Thanks!
> 
> Hongwei
> 
> 
> 
> -Original Message-
> From: tri...@samba.org [mailto:tri...@samba.org]
> Sent: Tuesday, October 13, 2009 6:23 AM
> To: Interoperability Documentation Help
> Cc: cifs-proto...@samba.org; p...@tridgell.net
> Subject: CAR: DRS option bits
> 
> Hi,
> 
> I'm still working on our DRSR DsGetNCChanges implementation. One
> puzzle I've hit is related to MS-DRSR 5.39 DRS Options. I'm receiving
> replication requests from a w2k8-R2 machine with the replication flags
> (ulFlags) set to 0x00200074. The bit 0x0020 is one of the 'X' bits
> in section 5.39, so I guess it is either an undocumented bit or the
> bitfield is incorrectly labelled in the docs.
> 
> Given the complexity of decoding WSPP bitfields, here is my decode of
> it for you to check:
> 
>   DRSUAPI_DRS_ASYNC_OP  = 0x0001,
>   DRSUAPI_DRS_GETCHG_CHECK  = 0x0002,
>   DRSUAPI_DRS_ADD_REF   = 0x0004,
>   DRSUAPI_DRS_SYNC_ALL  = 0x0008,
>   DRSUAPI_DRS_DEL_REF   = 0x0008,
>   DRSUAPI_DRS_WRIT_REP  = 0x0010,
>   DRSUAPI_DRS_INIT_SYNC = 0x0020,
>   DRSUAPI_DRS_PER_SYNC  = 0x0040,
>   DRSUAPI_DRS_MAIL_REP  = 0x0080,
>   DRSUAPI_DRS_ASYNC_REP = 0x0100,
>   DRSUAPI_DRS_IGNORE_ERROR  = 0x0100,
>

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

2009-10-23 Thread Kamen Mazdrashki 
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:    0x4823
bin_oid:      0x2A817A + 01 ('1.2.250.1')
attid_loword: 0x0001
 
attid:    0x87159F45
id_prefix:    0x4823
bid_oid:      0x2A817A + 8102 ('1.2.250.130')
attid_loword: 0x0082
 
attid:    0x85C6D3B9
id_prefix:    0x0DC7
bin_oid:      0x2A817A81 + 8002 ('1.2.250.16386')
attid_loword: 0x8002
 
attid:    0x9E0386A9
id_prefix:    0x3C60
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: 0x008933
Well, there is no such entry (please look in log file for Win2k8).
prefixMap entry we should find for this ATTID is id_prefix: 0x4823. 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.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
 
>-Original Message-
>From: Bill Wesse [mailto:bil...@microsoft.com]
>Sent: Friday, October 23, 2009 2:44 PM
>To: Kamen Mazdrashki
>Cc: p...@tridgell.net; cifs-proto...@samba.org
>Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
>prefixMap implementation
>
>Good morning again Kamen. I have completed my investigation of our
>prefixMap, MakeAttid() and OidFromAttid() on Windows 2003 &2008 R2:
>they are indeed functionally identical.
>
>So, something else is going on here, and we will need to duplicate your
>results under debug. To do that, I need to ask you to forward a copy of
>the LDIF file to me (I received the docs &conf file, but not the
>LDIF).
>
>Regards,
>Bill Wesse
>MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
>8055 Microsoft Way
>Charlotte, NC 28273
>TEL: +1(980) 776-8200
>CELL: +1(704) 661-5438
>FAX: +1(704) 665-9606
>
>-Original Message-
>From: Bill Wesse
>Sent: Thursday, October 22, 2009 11:15 AM
>To: 'Kamen Mazdrashki'
>Cc: p...@tridgell.net; cifs-proto...@samba.org
>Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
>prefixMap implementation
>
>Thanks for the advisory - I will follow up with you on the attid - I
>will be expanding my code study on this.
>
>Regards,
>Bill Wesse
>MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
>8055 Microsoft Way
>Charlotte, NC 28273
>TEL: +1(980) 776-8200
>CELL: +1(704) 661-5438
>FAX: +1(704) 665-9606
>
>
>-Original Message-
>From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com]
>Sent: Thursday, October 22, 2009 10:56 AM
>To: Bill Wesse
>Cc: p...@tridgell.net; cifs-proto...@samba.org
>Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
>prefixMap implementation
>
>Hi Bill,
>
>Currently this issue stops me from implementing MakeAttid() and
>OidFromAttid() to work transparently in all cases - from Win2k3 to
>Win2k8. Also I can't make a reasonable unit test for those functions.
>Nevertheless, it is not a 'show stopper' for me at this stage, as
>current implementation (following MS-DRSR) work well for Win2k3 and
>Win2k8 (without modifying schema).
>
>Attached you may find:
> - LDIF file;
> - 2 logs - from Win2k3 (Functional Level = Win 2000) and Win2k8-R2
>(Functional Level = Win 2008 R2);
> -

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

2009-10-26 Thread Kamen Mazdrashki 
Good evening Bill,
 
Thanks for the update.
 
BR,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

 
From: Bill Wesse [mailto:bil...@microsoft.com] 

Sent: Monday, October 26, 2009 4:56 PM

 To: Kamen Mazdrashki

 Cc: p...@tridgell.net; cifs-proto...@samba.org

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


 
Good morning Kamen – I am sending this update to advise you of my progress. I 
have coded the algorithms in C#, in advance of scanning the last data (ldif 
&py) you sent.
 
I expect to have some results for you by tomorrow morning at the latest (along 
with the Visual Studio project).
 
Thanks for your patience. 

Regards,

 Bill Wesse

 MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM

 8055 Microsoft Way

 Charlotte, NC 28273

 TEL: +1(980) 776-8200
CELL: +1(704) 661-5438

 FAX:  +1(704) 665-9606

 
From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] 

Sent: Friday, October 23, 2009 8:32 AM

 To: Bill Wesse

 Cc: p...@tridgell.net; cifs-proto...@samba.org

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


 
Hi Bill,
 
Sorry, I must have missed the LDIF. Here it is.
 
I have also gathered some data for you - the log file is bloated with other 
information, so here is just the most important observations from the log.
 
Win2k8
---
attid:   0x8933929C
id_prefix:  0x4823
bin_oid:0x2A817A + 01 ('1.2.250.1')
attid_loword: 0x0001
 
attid:   0x87159F45
id_prefix:  0x4823
bid_oid:0x2A817A + 8102 ('1.2.250.130')
attid_loword: 0x0082
 
attid:  0x85C6D3B9
id_prefix:  0x0DC7
bin_oid:0x2A817A81 + 8002 ('1.2.250.16386')
attid_loword: 0x8002
 
attid:   0x9E0386A9
id_prefix:  0x3C60
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: 0x008933
Well, there is no such entry (please look in log file for Win2k8).
prefixMap entry we should find for this ATTID is id_prefix: 0x4823. 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.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
 
>-Original Message-----
>From: Bill Wesse [mailto:bil...@microsoft.com]
>Sent: Friday, October 23, 2009 2:44 PM
>To: Kamen Mazdrashki
>Cc: p...@tridgell.net; cifs-proto...@samba.org
>Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
>prefixMap implementation
>
>Good morning again Kamen. I have completed my investigation of our
>prefixMap, MakeAttid() and OidFromAttid() on Windows 2003 &2008 R2:
>they are indeed functionally identical.
>
>So, something else is going on here, and we will need to duplicate your
>results under debug. To do that, I need to ask you to forward a copy of
>the LDIF file to me (I received the docs &conf file, but not the
>LDIF).
>
>Regards,
>Bill Wesse
>MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
>8055 Microsoft Way
>Charlotte, NC 28273
>TEL: +1(980) 776-8200
>CELL: +1(704) 661-5438
>FAX: +1(704) 665-9606
>
>-Original Message-
>From: Bill Wesse
>Sent: Thursday, October 22, 2009 11:15 AM
>To: 'Kamen Mazdrashki'
>Cc: p...@tridgell.net; cifs-proto...@samba.org
>Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 -
>prefixMap implementation
>
>

[cifs-protocol] Object(OR-Name) syntax implementation

2009-11-19 Thread Kamen Mazdrashki 
Hi,

While I was trying to implement "Object(OR-Name)" syntax handling in Samba, 
I've got some unexpected results.
There are several places to describe this syntax:
http://msdn.microsoft.com/en-us/library/cc223181%28PROT.13%29.aspx - from ADTS
http://msdn.microsoft.com/en-us/library/cc228440%28PROT.13%29.aspx - from DRSR

Documentation says (ADTS and DRSR) that values with "Object(OR-Name)" syntax 
are in 'object_DN' format which is in "Object(DS-DN)" format.
At first I got the impression, that "Object(OR-Name)" and "Object(DS-DN)" are 
the same.
But then, LDAP queries against AD always returns plain-dn DNs - even when 
'extended dn' control is passed.
So I come to a conclusion, 'object_DN' means "DN part from Object(DS-DN) 
syntax".

After some tests with DRSUAPI interface though, it turns that values with 
'OR-Name' syntax are transmitted in
";;dn" format which is "Object(DS-DN)" format!

At this point, I decided, that "Object(OR-Name)" is represented in two ways:
1. plain_dn - when working through LDAP
2. Object(DS-DN) - when transmitted using DRS interface

But then, after few hours of debugging/testing I was surprised to find out that 
through DRS interface, values with "Object(OR-Name)" syntax are transmitted as 
"Object(DN-Binary)"!


Here is some test data:
I am playing with "authOring" attribute (from MS Exchange 2003 provisioning)
Through DRS I am getting blob with value: 
0x96001c00167dcc23a03d3a4f99210ad60a99230f0105000515009ca04dcc46a0a763e4b37ba4f4012e0043004e003d00410064006d0069006e006900730074007200610074006f0072002c0043004e003d00550073006500720073002c00440043003d006b006d0061002d0065007800630068002c00440043003d0064006500760065006c000400

When I assume this value is in Object(DS-DN) format, it is correctly converted 
to following extended-DN:
;;CN=Administrator,CN=Users,DC=kma-exch,DC=devel

However, the above mentioned extended-DN does not match exactly the blob value 
when it is converted back to blob using "Object(DS-DN)" syntax handling. 

On the other hand, when using "Object(DN-Binary)" syntax implementation, 
forward/backward conversions match perfectly. I.e. the abovementioned blob 
value should be decoded to DN-Binary value:
B:0::;;CN=Administrator,CN=Users,DC=kma-exch,DC=devel";


I think there is a bug in documentation?
Please, clarify?


Thanks,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always present

2010-01-14 Thread Kamen Mazdrashki 
Thanks for the update.
 
CU,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

 
From: Bill Wesse [mailto:bil...@microsoft.com] 

Sent: Thursday, January 14, 2010 4:24 PM

 To: Kamen Mazdrashki

 Cc: p...@tridgell.net; abart...@samba.org; cifs-proto...@samba.org

 Subject: Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always 
present


 
Good morning once again Kamen! Here is what’s up with the TDI…
 
Your comment:
Btw, one interesting observation during my tests – adding ‘msDS-IntId’ on 
classSchema object passes nicely during object creation. After that, trying to 
modify this attribute value leads to “CONSTRAINT_VIOLATION”. And I am wondering 
– what is the meaning of ‘msDS-IntId’ when used in a classSchema object
 
Response:
Essentially, this means that a client cannot modify the objectCategory of an 
instance of a base schema class (the DSA can do this on its own behalf only).
 
On another note:
[MS-ADTS] 3.1.1.2.3 Attributes 
(http://msdn.microsoft.com/en-us/library/cc223202(PROT.13).aspx) says the DC 
returns LDAP error unwillingToPerform on any attempt to specify msDS-IntId on 
an Add operation.
 
I have alerted those concerned with the TDI to this; the response to your main 
question (…a ‘steady’ rule when to create ‘msDS-IntId’ value for an attribute 
in the schema) is still pending.
 
Thanks for your patience.
 
Regards,

 Bill Wesse

 MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM

 8055 Microsoft Way

 Charlotte, NC 28273

 Email:   bil...@microsoft.com
Tel:  +1(980) 776-8200
Cell: +1(704) 661-5438

 Fax: +1(704) 665-9606

 
From: Bill Wesse 

Sent: Thursday, December 31, 2009 8:41 AM

 To: 'Kamen Mazdrashki'

 Cc: 'p...@tridgell.net'; 'abart...@samba.org'; 'cifs-proto...@samba.org'

 Subject: RE: Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always 
present


 
Good morning Kamen – I neglected to advise you I filed a Technical 
Documentation Issue (TDI) concerning the msDS-IntId attribute. This is still 
under investigation by our document developers, and I will advise you as soon 
as some results are forthcoming.
 
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: Bill Wesse 

Sent: Wednesday, December 16, 2009 9:52 AM

 To: 'Kamen Mazdrashki'

 Cc: p...@tridgell.net; abart...@samba.org; cifs-proto...@samba.org

 Subject: RE: Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always 
present (SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation)


 
Thanks for the update Kamen – I have created the following case to track our 
work. Unless you think otherwise, I will archive the old case (SRX091020600112 
[MS-DRSR] section 5.12.2 - prefixMap implementation)).
 
SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always present
 
I expect to be able to begin work later today – or by tomorrow morning at the 
latest.
 
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.mazdras...@postpath.com] 

Sent: Tuesday, December 15, 2009 9:08 PM

 To: Bill Wesse

 Cc: p...@tridgell.net; abart...@samba.org; cifs-proto...@samba.org

 Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap 
implementation


 
Hi Bill,
 
Finally I have a “msDS-IntId” attribute.
You can find the test in “source4/lib/ldb/tests/python/ldap_schema.py” python 
script.
You can execute the script from ‘source4’ directory as follows:
lib/ldb/tests/python/ldap_schema.py -UAdministrator%password w2k8
This test is only in my branch thus you can download it from (sorry for the 
inconvenience):
http://repo.or.cz/w/Samba/kamenim.git/snapshot/1de38d8251c6df7fb23d68033f57c1f8f53bcded.tar.gz
 
According to MS-ADTS 
http://msdn.microsoft.com/en-us/library/cc223202%28PROT.13%29.aspx, 
msDS-IntId is “Present on attributeSchema 
<http://msdn.microsoft.com/en-us/library/cc221662%28PROT.13%29.aspx>  objects 
added when forest functional level is DS_BEHAVIOR_WIN2003 or greater with 
FLAG_SCHEMA_BASE_OBJECT not present in systemFlags 
<http://msdn.microsoft.com/en-us/library/cc220919%28PROT.13%29.aspx> ”.
However, when running the test against w2k8 there are lot of attributes that 
does not obey this rule.
Please see attached file “w2k8_msDS-IntId.txt”.
 
At first I thought that those attributes has attributeIDs that can be 
encoded/decoded using ‘default prefixMap’.
After examining the list though, it turns out this is not the case for majority 
of those attributes.
Please see at

Re: [cifs-protocol] Structure of prefixMap over LDAP

2010-01-15 Thread Kamen Mazdrashki 
Hi Obaid,

Could you please point out where those default 39 entries for prefixMap are 
described?
I am looking at: 
http://msdn.microsoft.com/en-us/library/cc228445%28PROT.13%29.aspx
and there are only 19 default prefixes listed here.



Thanks,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

> -Original Message-
> From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-
> boun...@cifs.org] On Behalf Of Obaid Farooqi
> Sent: Thursday, January 14, 2010 8:27 PM
> To: abart...@samba.org
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: Re: [cifs-protocol] Structure of prefixMap over LDAP
> 
> Hi Andrew:
> Please let me know if the following answers your question. If yes, I'll
> consider this issue resolved.
> 
> Regards,
> Obaid Farooqi
> Sr. Support Escalation Engineer | Microsoft
> 
> -Original Message-
> From: Obaid Farooqi
> Sent: Wednesday, January 06, 2010 2:03 PM
> To: 'abart...@samba.org'
> Cc: 'cifs-proto...@samba.org'; 'p...@tridgell.net'
> Subject: RE: Structure of prefixMap over LDAP
> 
> Hi Andrew,
> 
> We understand the reasons for your inquiry as to the exact content and
> format of the LDAP attribute prefixMap.  We’d like to propose that we
> explain the content and format of the attribute in this mail, and after
> that, discuss whether it belongs in the documentation.
> 
> As you’ve no doubt already determined, prefixMap is related to the
> ‘Prefix Table’ documented in MS-DRSR and used in ATTRTYP-to-OID
> conversion; it’s also documented in MS-DRSR (section 5.16.4.)  The
> prefixMap attribute itself though serves no purpose in the context of
> "replication-protocol" beyond locally storing the state necessary for a
> replication partner to decompress an implementation-specific means of
> representing OIDs.  The attribute itself is never requested or written
> over-the-wire by any Windows implementation nor is it necessary for a
> partner DC to know how the map is stored.  DRSR does not reference the
> attribute by name or refer to where the map is maintained in any more
> general sense; it only provides the necessary detail to define how the
> OIDs are decompressed to their native form on the partner DC.
> 
> More specifically – prefixMap is a cache of the parts of the Prefix
> Table that relate to user-defined attributes (which is a subset of the
> whole Prefix Table used in MS-DRSR.)  Theoretically, this structure
> could have been built on the fly and not cached.  Certainly this cache
> could have been stored somewhere else, besides in an attribute of the
> directory, e.g. on a protocol-inaccessible area in memory or on disk
> (i.e. not in abstract state).  We certainly didn’t envisage any need or
> value in a client reading it or writing it – we would have included the
> entire Prefix Table were that the case.  So if we don’t want any client
> to ever read or write it then “why is it an attribute?”.  Basically,
> because it was a convenient place for our implementation to locally
> store it – our directory implementation IS a handy place to store
> things.  Plus, for the purposes of debugging our implementation, being
> able to read implementation-specific values via LDAP is very practical
> (since we read everything else that way too).
> 
> 
> 
> Anyway, the prefixMap structure contains user-defined attribute info
> for ATTRTYP-to-OID conversion.  This means e.g. for Windows 2008 R2 it
> does not contain the ATTRTYP-to-OID conversion info for the first 39
> attributes in the Prefix Table as used by MS-DRSR, just the ‘rest’ of
> them.  When this attribute has a value, it is stored as a binary blob
> with the following formatting:
> 
> 1. First 4 bytes are a DWORD showing the total number of prefixes
> represented in the map.  That is, the number of elements in the series
> of data structures described below.
> 
> 2. Next 4 bytes are a DWORD showing the total size of the binary blob,
> including both these first 8 bytes and any remaining bytes representing
> OID prefixes.
> 
> 3. Following these first 8 bytes is a series of variable length data
> structures, each element in the series representing a single mapping
> between an OID prefix and the internal WORD value representing the
> prefix.  The WORD is used as the high-word of a DWORD holding an
> internal attribute type.  These internal attribute types are not useful
> via LDAP, they are used only in the replication protocol. Each element
> of the series has this format:
>   - First 2 bytes are a WORD holding the internal WORD value.
>   - Next 2 bytes are a WORD holdi

Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP

2010-02-01 Thread Kamen Mazdrashki 
Thanks Bill,

Btw, we've implemented prefixMap over ldap dump handler and it works great.
Many thanks for publishing the format.

BR,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

> -Original Message-
> From: Bill Wesse [mailto:bil...@microsoft.com]
> Sent: Monday, February 01, 2010 3:14 PM
> To: abart...@samba.org; Kamen Mazdrashki
> Cc: Sebastian Canevari; Obaid Farooqi; p...@tridgell.net; cifs-
> proto...@samba.org
> Subject: RE: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of
> prefixMap over LDAP
> 
> Good morning again. Sebastian will be back in the office today; I have
> transferred case ownership back to him.
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
> 
> 
> -Original Message-
> From: Bill Wesse
> Sent: Thursday, January 28, 2010 11:46 AM
> To: 'abart...@samba.org'; 'kamen.mazdras...@postpath.com'
> Cc: Sebastian Canevari; Obaid Farooqi; 'p...@tridgell.net'; 'cifs-
> proto...@samba.org'
> Subject: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of
> prefixMap over LDAP
> 
> Good day Andrew & Kamen. Please note that my colleague Sebastian (who
> took ownership of this case from Obaid) is out of the office for the
> next few days.
> 
> In the interim, I will be your contact. Thanks in advance for your
> patience!
> 
> Andrew - I sent a status update request for the TDI (which has been in
> suspense since one of your previous emails (shown at the end of this
> message). I will advise you as soon as I receive a response.
> 
> Kamen - I have already performed some investigation concerning those 20
> other prefixMap entries, and expect to follow up with your tomorrow
> morning.
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
> 
> -Original Message-
> From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com]
> Sent: Friday, January 15, 2010 3:09 AM
> To: Obaid Farooqi; abart...@samba.org
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP
> 
> Hi Obaid,
> 
> Could you please point out where those default 39 entries for prefixMap
> are described?
> I am looking at: <http://msdn.microsoft.com/en-
> us/library/cc228445%28PROT.13%29.aspx>
> and there are only 19 default prefixes listed here.
> 
> 
> 
> Thanks,
> Kamen Mazdrashki
> kamen.mazdras...@postpath.com <mailto:kamen.mazdras...@postpath.com>
> <http://repo.or.cz/w/Samba/kamenim.git>
> -
> CISCO SYSTEMS BULGARIA EOOD
> <http://www.cisco.com/global/BG/>
> 
> -Original Message-
> From: Andrew Bartlett [mailto:abart...@samba.org]
> Sent: Tuesday, December 15, 2009 1:39 AM
> To: Obaid Farooqi
> Cc: cifs-proto...@samba.org; p...@tridgell.net
> Subject: RE: Structure of prefixMap over LDAP
> 
> On Tue, 2009-12-15 at 06:22 +, Obaid Farooqi wrote:
> > Hi Andrew:
> > In an effort to fully understand your goals, please explain what you
> > are looking  to achieve through the addition of documentation that
> > defines the internal structure of the prefixMap attribute.
> 
> As a start:
> 
> The ability to generate a matching prefixMap attribute, should any
> client request it.  The ability to verify prefixMap values over DRS and
> LDAP to confirm consistency.  The ability to include prefixMap values
> in comparison tests we may make between AD and Samba4.  An
> understanding of how the contents of this attribute interacts with
> msDs-intID and other prefix mapping functionality.
> 
> Finally, I'm simply looking to ensure that the documentation set
> explains the format of every value (generated or otherwise) in AD, so
> we don't have to come back to this later.
> 
> Thanks,
> 
> Andrew Bartlett
> 
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team   http://samba.org
> Samba Developer, Cisco Inc.

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[cifs-protocol] Replicating deleted object procedure clarifications

2010-05-18 Thread Kamen Mazdrashki 
Dear Dochelp,

I am currently trying to refactor Delete object implementation in Samba and
I need some help
with algorithm used for deleting objects and how the deletion is replicated
to other DCs.

Reference:
 ProcessGetNCChangesReply [MS-DRSR] -
http://msdn.microsoft.com/en-us/library/dd207758(v=PROT.13).aspx
UpdateObject [MS-DRSR] -
http://msdn.microsoft.com/en-us/library/dd207780(v=PROT.13).aspx
<http://msdn.microsoft.com/en-us/library/dd207758(v=PROT.13).aspx> Delete
Operation [MS-ADTS] -
http://msdn.microsoft.com/en-us/library/cc223480(v=PROT.13).aspx

<http://msdn.microsoft.com/en-us/library/cc223480(v=PROT.13).aspx>Consider
following sutiation:
0. We have two DCs configuration.
We have an OU object with following props:
  dn: OU=TEST_DELETE_0417,DC=samba,DC=devel
  objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729

1. We delete this OU on DC1. The state of this object on each dc should be
as follows:
  DC1:
  dn:
OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted
Objects,DC=samba,DC=devel
  objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
  isDeleted: TRUE
  isRecycled: TRUE
  DC2:
  dn: OU=TEST_DELETE_0417,DC=samba,DC=devel
  objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729

2. Replication is triggered from DC1 to DC2.
Now, according to UpdateObject() procedure, we will identify that Object's
DN has changed from
"dn: OU=TEST_DELETE_0417,DC=samba,DC=devel"
to "dn:
OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted
Objects,DC=samba,DC=devel".
Hence we will modify object's DN (calling PerformModifyDNOperation()
operation).
Which will make this object a Deleted-object right?
While progressing further in UpdateObject() procedure, we will check and
see, that 'isDeleted'
attribute value is TRUE, so we shall call RemoveObj() procedure. At this
point I am a little bit puzzled as
there are two possible outcomes from this procedure:
1. Object's RDN should be transformed to a delete-mangled RDN. So we should
end with an RDN like:
 
TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72
right?
2. Or, as the object is already under "Deleted Object" container (moved
there by previous call to PerformModifyOperation()),
RemoveObj() procedure should delete it further - i.e. if the object is a
Tombstone, it will be completely removed.


Sorry that my description gets so messy.
Basically what UpdateObject() states is that first we should execute
PerformModifyOperation() and then RemoveObj().
Which is a little bit confusing, as PerformModifyOperation() will turn the
object into a Deleted-object.
Calling RemoveObj() later will actually act on already modified object, so I
wonder - how does RemoveObj()
knows that we just converted the object and this object should not be
completely removed?

Another possibility is for PeformModifyOperation() to determine that target
DN will move the object under
"Deleted Objects" container, and in this case to modify only Attribute
values on the object, but not to call
PerformModifyDNOperation() operation?

-- 
CU,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://gitweb.samba.org/?p=kamenim/samba.git;a=summary
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] [REG:110051857479854] RE: Replicating deleted object procedure clarifications

2010-05-23 Thread Kamen Mazdrashki 
Hi Hongwei,

You are totally right and you understood my question, thanks!

The thing is that although the comment before calling RemoveObj() describes
what should happen next,
RemoveObj() descriptions itself doesn't mention about this situation at all.
I think the documentation is not complete enough and RemoveObj() prototype
and description should
make a distinction between 'mangling object DN, state and update attributes'
and just 'update attributes'.
Now, if someone reads the description it looks like RemoveObj() will act
blindly on DSNAME given,
which should lead to deleting the object, modified already by
PerformModifyOperation() :)

Thanks,
Kamen


On Sat, May 22, 2010 at 02:40, Hongwei Sun  wrote:

>  Kamen,
>
>
>
>For your question regarding the algorithm used in UpdateObject() , as
> documented in 4.1.10.6.9 of MS-DRSR,  I think that the RemoveObj()  was
> performed after PerformModifyOperation just to ensure the attributes on
> the deleted object conform to the invariants of a tombstone or
> deleted-object(see 3.1..1.5.5 of  MS-ADTS).   This is mentioned in the
> comments of the algorithm before RemoveObj is called.Furthermore, as per
> 5.154 of MS-DRSR, RemoveObj procedure performs a delete operation on an
> object so the targeted object will be transformed to a deleted-object or a
> tombstone ,depending on the state of the Recycle Bin option feature.  This
> includes modifying the attributes and moving into the Deleted Container of
> its NC.  But it will not remove the objects from the directory directly.
> If the object after PerformModifyOperation already conforms to the invariant
> of deleted-object or tombstone,  the RemoveObj may do nothing to the object.
>
>
>
>   Please let me know if I understand you question properly and if you have
> further questions.
>
>
>
> Thanks!
>
>
>
> Hongwei
>
>
>
>
>
>
>
> *From:* cifs-protocol-boun...@cifs.org [mailto:
> cifs-protocol-boun...@cifs.org] *On Behalf Of *Kamen Mazdrashki
>
> *Sent:* Tuesday, May 18, 2010 7:33 AM
> *To:* Interoperability Documentation Help; cifs-proto...@samba.org;
> p...@tridgell.net
> *Subject:* [cifs-protocol] Replicating deleted object procedure
> clarifications
>
>
>
> Dear Dochelp,
>
>
>
> I am currently trying to refactor Delete object implementation in Samba and
> I need some help
>
> with algorithm used for deleting objects and how the deletion is replicated
> to other DCs.
>
>
>
> Reference:
>
>  ProcessGetNCChangesReply [MS-DRSR] -
> http://msdn.microsoft.com/en-us/library/dd207758(v=PROT.13).aspx
>
> UpdateObject [MS-DRSR] -
> http://msdn.microsoft.com/en-us/library/dd207780(v=PROT.13).aspx
>
>  Delete Operation [MS-ADTS] -
> http://msdn.microsoft.com/en-us/library/cc223480(v=PROT.13).aspx
>
>
>
> Consider following sutiation:
>
> 0. We have two DCs configuration.
>
> We have an OU object with following props:
>
>   dn: OU=TEST_DELETE_0417,DC=samba,DC=devel
>
>   objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
>
>
>
> 1. We delete this OU on DC1. The state of this object on each dc should be
> as follows:
>
>   DC1:
>
>   dn:
> OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted
> Objects,DC=samba,DC=devel
>
>   objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
>
>   isDeleted: TRUE
>
>   isRecycled: TRUE
>
>   DC2:
>
>   dn: OU=TEST_DELETE_0417,DC=samba,DC=devel
>
>   objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
>
>
>
> 2. Replication is triggered from DC1 to DC2.
>
> Now, according to UpdateObject() procedure, we will identify that Object's
> DN has changed from
>
> "dn: OU=TEST_DELETE_0417,DC=samba,DC=devel"
>
> to "dn:
> OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted
> Objects,DC=samba,DC=devel".
>
> Hence we will modify object's DN (calling PerformModifyDNOperation()
> operation).
>
> Which will make this object a Deleted-object right?
>
> While progressing further in UpdateObject() procedure, we will check and
> see, that 'isDeleted'
>
> attribute value is TRUE, so we shall call RemoveObj() procedure. At this
> point I am a little bit puzzled as
>
> there are two possible outcomes from this procedure:
>
> 1. Object's RDN should be transformed to a delete-mangled RDN. So we should
> end with an RDN like:
>
>  
> TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72
> right?
>
> 2. Or, as the object is already under "Deleted Object" container (moved
> there by previo