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.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 4:16 AM To: Bill Wesse; 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 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] 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: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation You are very welcome. Could you advise me concerning how much this is affecting your implementation development, so that I can set the TDI priority appropriately? I have cross-compared the Windows 2003 and Windows 2008 R2 implementations of the MakeAttid() and OidFromAttid() functions; there appear to be no functional changes. I suspect there is some corner-case not fully described in the attid composition in MakeAttid (lastValue ≥ 16384). procedure MakeAttid(var t: PrefixTable, o: OID): ATTRTYP ... /*compose the attid*/ lowerWord := lastValue mod 16384 if lastValue ≥ 16384 then /*mark it so that it is known to not be the whole lastValue*/ lowerWord := lowerWord + 32768 endif Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 4:16 AM To: Bill Wesse; 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 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
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); - 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.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: Thursday, October 22, 2009 5:50 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 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: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation You are very welcome. Could you advise me concerning how much this is affecting your implementation development, so that I can set the TDI priority appropriately? I have cross-compared the Windows 2003 and Windows 2008 R2 implementations of the MakeAttid() and OidFromAttid() functions; there appear to be no functional changes. I suspect there is some corner-case not fully described in the attid composition in MakeAttid (lastValue ≥ 16384). procedure MakeAttid(var t: PrefixTable, o: OID): ATTRTYP ... /*compose the attid*/ lowerWord := lastValue mod 16384 if lastValue ≥ 16384 then /*mark it so that it is known to not be the whole lastValue*/ lowerWord := lowerWord + 32768 endif Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 4:16 AM To: Bill Wesse; 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 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
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, DRSUAPI_DRS_TWOWAY_SYNC = 0x0200, DRSUAPI_DRS_CRITICAL_ONLY = 0x0400, DRSUAPI_DRS_GET_ANC = 0x0800, DRSUAPI_DRS_GET_NC_SIZE = 0x1000, DRSUAPI_DRS_LOCAL_ONLY= 0x1000, DRSUAPI_DRS_SYNC_BYNAME = 0x4000, DRSUAPI_DRS_REF_OK= 0x4000, DRSUAPI_DRS_FULL_SYNC_NOW = 0x8000, DRSUAPI_DRS_NO_SOURCE = 0x8000, DRSUAPI_DRS_FULL_SYNC_PACKET = 0x0002, DRSUAPI_DRS_REF_GCSPN = 0x0010, DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING = 0x0080, DRSUAPI_DRS_SYNC_FORCED = 0x0200, DRSUAPI_DRS_DISABLE_AUTO_SYNC = 0x0400, DRSUAPI_DRS_DISABLE_PERIODIC_SYNC = 0x0800, DRSUAPI_DRS_USE_COMPRESSION = 0x1000, DRSUAPI_DRS_NEVER_NOTIFY
Re: [cifs-protocol] DRS option bits
Big G! :) Sebastian Canevari Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7849 e-mail: seba...@microsoft.com -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Hongwei Sun Sent: Thursday, October 22, 2009 5:09 PM 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, DRSUAPI_DRS_TWOWAY_SYNC = 0x0200, DRSUAPI_DRS_CRITICAL_ONLY = 0x0400, DRSUAPI_DRS_GET_ANC = 0x0800, DRSUAPI_DRS_GET_NC_SIZE = 0x1000, DRSUAPI_DRS_LOCAL_ONLY= 0x1000, DRSUAPI_DRS_SYNC_BYNAME = 0x4000, DRSUAPI_DRS_REF_OK= 0x4000, DRSUAPI_DRS_FULL_SYNC_NOW = 0x8000, DRSUAPI_DRS_NO_SOURCE = 0x8000,
