[cifs-protocol] Errors when doing a DsAddEntry
We have been looking at DRSUAPI/DsAddEntry, and have a few questions. We are trying to implement subdomain support in Samba4 before the plugfest. We have been able to generate error cases that do not seem to be 'possible' in the docs. Can you please clarify exactly what errors this function should be able to return, and document how to avoid these: in join-s1.txt we have an error that is only listed in the docs when removing a DC from the domain. extended_err : WERR_DS_ROLE_NOT_VERIFIED This is currently blocking us. Our only theory is that we must perform a replication cycle before we do this call. in join-s1-2.txt we have another error, that we worked around by creating the partitions object before creating the server object. However, as we need to match the server-side behaviour, we need to know the undocumented circumstances that cause this error. extended_err : WERR_DS_NO_CROSSREF_FOR_NC Finally, is there any documentation of the high-level procedure for creating a subdomain? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org lpcfg_load: refreshing parameters from /home/tridge/samba/git/prefix.s2/etc/smb.conf drsuapi_DsBind: struct drsuapi_DsBind in: struct drsuapi_DsBind bind_guid: * bind_guid: e24d201a-4fd6-11d1-a3da-f875ae0d bind_info: * bind_info: struct drsuapi_DsBindInfoCtr length : 0x001c (28) info : union drsuapi_DsBindInfo(case 28) info28: struct drsuapi_DsBindInfo28 supported_extensions : 0x0fefff7f (267386751) 1: DRSUAPI_SUPPORTED_EXTENSION_BASE 1: DRSUAPI_SUPPORTED_EXTENSION_ASYNC_REPLICATION 1: DRSUAPI_SUPPORTED_EXTENSION_REMOVEAPI 1: DRSUAPI_SUPPORTED_EXTENSION_MOVEREQ_V2 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHG_COMPRESS 1: DRSUAPI_SUPPORTED_EXTENSION_DCINFO_V1 1: DRSUAPI_SUPPORTED_EXTENSION_RESTORE_USN_OPTIMIZATION 0: DRSUAPI_SUPPORTED_EXTENSION_ADDENTRY 1: DRSUAPI_SUPPORTED_EXTENSION_KCC_EXECUTE 1: DRSUAPI_SUPPORTED_EXTENSION_ADDENTRY_V2 1: DRSUAPI_SUPPORTED_EXTENSION_LINKED_VALUE_REPLICATION 1: DRSUAPI_SUPPORTED_EXTENSION_DCINFO_V2 1: DRSUAPI_SUPPORTED_EXTENSION_INSTANCE_TYPE_NOT_REQ_ON_MOD 1: DRSUAPI_SUPPORTED_EXTENSION_CRYPTO_BIND 1: DRSUAPI_SUPPORTED_EXTENSION_GET_REPL_INFO 1: DRSUAPI_SUPPORTED_EXTENSION_STRONG_ENCRYPTION 1: DRSUAPI_SUPPORTED_EXTENSION_DCINFO_V01 1: DRSUAPI_SUPPORTED_EXTENSION_TRANSITIVE_MEMBERSHIP 1: DRSUAPI_SUPPORTED_EXTENSION_ADD_SID_HISTORY 1: DRSUAPI_SUPPORTED_EXTENSION_POST_BETA3 0: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V5 1: DRSUAPI_SUPPORTED_EXTENSION_GET_MEMBERSHIPS2 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V6 1: DRSUAPI_SUPPORTED_EXTENSION_NONDOMAIN_NCS 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V8 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREPLY_V5 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREPLY_V6 1: DRSUAPI_SUPPORTED_EXTENSION_ADDENTRYREPLY_V3 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREPLY_V7 1: DRSUAPI_SUPPORTED_EXTENSION_VERIFY_OBJECT 0: DRSUAPI_SUPPORTED_EXTENSION_XPRESS_COMPRESS 0: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V10 0: DRSUAPI_SUPPORTED_EXTENSION_RESERVED_PART2 0: DRSUAPI_SUPPORTED_EXTENSION_RESERVED_PART3 site_guid: ---- pid : 0x (0) repl_epoch : 0x (0) drsuapi_DsBind: struct drsuapi_DsBind out: struct drsuapi_DsBind bind_info: * bind_info: struct drsuapi_DsBindInfoCtr length : 0x0030 (48) info : union drsuapi_DsBindIn
Re: [cifs-protocol] FRS clarification about VVJOIN in FRS
Hi Matthieu, thank you for your question. A member of the protocol documentation team will be in touch with you soon. Josh Curry | Escalation Engineer | US-CSS Developer Support Core (DSC) Protocol Team P +1 469 775 7215 One Microsoft Way, 98052, Redmond, WA, USA http://support.microsoft.com -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Tuesday, August 30, 2011 6:09 PM To: Interoperability Documentation Help; p...@tridgell.net; cifs-proto...@samba.org Subject: FRS clarification about VVJOIN in FRS Hello Dochelp, I have some problems to understand something in the join process related to VVJOIN. In paragraph "3.3.4.4.4 COMM_COMMAND Is CMD_JOINING" we have at the end After the CMD_JOINED packet is sent: * If a connection VVJoin needs to be performed, FRS MUST go through the process specified in the following section. * If a connection VVJoin does not need to be performed, the upstream partner MUST send unknown change orders to the downstream partner based on the downstream partner version vector. And in paragraph "3.3.4.4.4.1 Connection VVJoin" FRS MUST perform Connection VVJoin when either of the following conditions is true: * P_IN.COMM_LAST_JOIN_TIME is 1. * Last connection session establishment (Join) time of the outbound connection is 1. During VVJoin, the upstream partner MUST send out a CMD_REMOTE_CO packet for each file Due to the way FRS1 is redacted I understand that the upstream partner when receiving a packet with a CMD_JOINING (P_IN) it must check what is described at 3.3.4.4.4.1in order to determine if should do a "simple" join or a VVJoin. Among the condition to determine if the join should be VVJoin I have the impression that the condition "P_IN.COMM_LAST_JOIN_TIME is 1." is always true, as if I understand correctly P_IN referrer to the packet with the CMD_JOINING command and in paragraph "3.3.4.4.3 COMM_COMMAND Is CMD_START_JOIN", which describe how the next packet that is to say a packet with CMD_JOINING, it is said that COMM_LAST_JOIN_TIME must be set to 1. Can you confirm ? Also I'd like to understand more what "unknown change orders to the downstream partner based on the downstream partner version vector." means, and if possible I'd like to have an example. Thanks. Matthieu. -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] FRS clarification about VVJOIN in FRS
Hello Dochelp, I have some problems to understand something in the join process related to VVJOIN. In paragraph "3.3.4.4.4 COMM_COMMAND Is CMD_JOINING" we have at the end After the CMD_JOINED packet is sent: * If a connection VVJoin needs to be performed, FRS MUST go through the process specified in the following section. * If a connection VVJoin does not need to be performed, the upstream partner MUST send unknown change orders to the downstream partner based on the downstream partner version vector. And in paragraph "3.3.4.4.4.1 Connection VVJoin" FRS MUST perform Connection VVJoin when either of the following conditions is true: * P_IN.COMM_LAST_JOIN_TIME is 1. * Last connection session establishment (Join) time of the outbound connection is 1. During VVJoin, the upstream partner MUST send out a CMD_REMOTE_CO packet for each file Due to the way FRS1 is redacted I understand that the upstream partner when receiving a packet with a CMD_JOINING (P_IN) it must check what is described at 3.3.4.4.4.1in order to determine if should do a "simple" join or a VVJoin. Among the condition to determine if the join should be VVJoin I have the impression that the condition "P_IN.COMM_LAST_JOIN_TIME is 1." is always true, as if I understand correctly P_IN referrer to the packet with the CMD_JOINING command and in paragraph "3.3.4.4.3 COMM_COMMAND Is CMD_START_JOIN", which describe how the next packet that is to say a packet with CMD_JOINING, it is said that COMM_LAST_JOIN_TIME must be set to 1. Can you confirm ? Also I'd like to understand more what "unknown change orders to the downstream partner based on the downstream partner version vector." means, and if possible I'd like to have an example. Thanks. Matthieu. -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111081664438980] RE: Level 257 FindFirst rejected by some Windows servers even though NTLM
Sorry about that - I don't actually have the test machines (I couldn't find a WindowsCE machine to test with) and the user didn't say what the test program was - but I think it was the "dir" command. I will ask him. On Tue, Aug 30, 2011 at 3:04 PM, Hongwei Sun wrote: > Steve, > > Any update ? > > Thanks! > > Hongwei > > > -Original Message- > From: Hongwei Sun > Sent: Thursday, August 25, 2011 4:26 PM > To: 'Steve French' > Cc: Edgar Olougouna; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case > Email > Subject: RE: [REG:111081664438980] RE: [cifs-protocol] Level 257 FindFirst > rejected by some Windows servers even though NTLM > > Steve, > > What program or API are you using on Windows client to test FIND_FIRST2 > command ? Have you observed that the same Windows client sends the > different information level while connecting to different server ? The > client (redirector) maps the application-provided [MS-FSCC] information > levels to a SMB information Level. SMB_FIND_FILE_BOTH_DIRECTORY_INFO is > mapped to FileBothDirectoryInformation passed from the application. I just > want to check to see how this is passed from the application. > > Thanks! > > Hongwei > > > -Original Message- > From: Steve French [mailto:smfre...@gmail.com] > Sent: Wednesday, August 24, 2011 4:23 PM > To: Hongwei Sun > Cc: Edgar Olougouna; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case > Email > Subject: Re: [REG:111081664438980] RE: [cifs-protocol] Level 257 FindFirst > rejected by some Windows servers even though NTLM > > On Tue, Aug 23, 2011 at 10:43 PM, Hongwei Sun wrote: >> Steve, >> >> Windows CE is not within the scope of protocol documentation, such as >> MS-SMB and MS-CIFS. Therefore it is understandable that it doesn't behave >> as specified in the protocol documents. > > This is more about what Windows clients do not about the WindowsCE server. > > Clearly windows clients works (to WindowsCE server) - and it appears it is > because they choose levels carefully to avoid the WindowsCE server problems > > instead of > FIND_FILE_DIRECTORY_INFO (level 257) > nor > FIND_FILE_FULL_DIRECTORY_INFO (258) > nor > FIND_FILE_ID_FULL_DIRECTORY_INFO (262) > > Windows clients (XP, Vista, etc) know enough to send > SMB_FIND_FILE_BOTH_DIRECTORY_INFO (260) > > which doesn't make sense since FIND_FILE_BOTH_DIRECTORY_INFO requires the > server to return the short name (which no longer seems relevant to windows > clients but they are requesting it - even of WindowsCE). > > Windows is NOT returning operation not supported (or the eqiuvalent) to the > application, rather it is selectively choosing to use level 260 (rather than > the 3 other more logical find levels) > > So the question is - how does Windows (clients) determine which level to > request on FindFirst - in particular when not to use 257, 258 or > 262 and fall back to 260? > >> As far as Windows systems, as per 2.2.2.3.1 MS-CIFS, for Windows NT >> and earlier, the Find information levels supported are clearly >> specified >> >> SMB_INFO_STANDARD 0x0001 >> (LANMAN2.0) >> SMB_INFO_QUERY_EA_SIZE 0x0002 >> (LANMAN2.0) >> SMB_INFO_QUERY_EAS_FROM_LIST 0x0003 (LANMAN2.0) >> SMB_FIND_FILE_DIRECTORY_INFO 0x0101 (NT LANMAN) >> SMB_FIND_FILE_FULL_DIRECTORY_INFO 0x0102 (NT LANMAN) >> SMB_FIND_FILE_NAMES_INFO 0x0103 (NT LANMAN) >> SMB_FIND_FILE_BOTH_DIRECTORY_INFO 0x0104 (NT LANMAN) >> >> For Windows 2000 and later , in addition to the levels above , the >> following levels are added as per MS-SMB 2.2.6.1.1 >> >> SMB_FIND_FILE_ID_FULL_DIRECTORY_INFO 0x0105 (NT LANMAN) >> SMB_FIND_FILE_ID_BOTH_DIRECTORY_INFO 0x0106 (NT LANMAN) >> >> As per 2.2.8 MS-CIFS, The client MUST map the application-provided >> [MS-FSCC] information levels to SMB information Levels. For all other >> [MS-FSCC] information levels, the client MUST fail the request with >> STATUS_NOT_SUPPORTED. In some case, the client MUST send a fixed level. >> For example, a client that has not negotiated long names support MUST >> request only SMB_INFO_STANDARD. >> >> Please let us know if you have more questions. >> >> Thanks! >> >> Hongwei >> >> >> >> >> -Original Message- >> From: cifs-protocol-boun...@cifs.org >> [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Steve French >> Sent: Thursday, August 18, 2011 4:54 PM >> To: Edgar Olougouna >> Cc: p...@tridgell.net; cifs-proto...@samba.org >> Subject: Re: [cifs-protocol] Level 257 FindFirst rejected by some >> Windows servers even though NTLM >> >> It looks like Windows CE takes (only?) level 260 but I can't easily prove it >> without access to a test system (I just have some customer traces) - so how >> does Windows clients (Windows XP/Vista/7 etc.) determine which FindFirst >> level to send to these given that the Microsoft server in this
Re: [cifs-protocol] [REG:111082117135230] RE: Initial replication of sysvol through FRS
Yes, this is right. Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Tuesday, August 30, 2011 3:13 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [REG:111082117135230] RE: Initial replication of sysvol through FRS Hi Hongwei, On 30/08/2011 21:58, Hongwei Sun wrote: > Matthieu, > > As per 2.3.2.2 MS-FRS1, A domain MUST have only one NTFRS replica set > object of type SYSVOL. The fRSReplicaSetType > attribute of a SYSVOL type object MUST be set to 2. Based on this, the > FRS can go through all the NTFRS Replica Set Objects to find the correct > replica set for SYSVOL. > >Please let me know if this makes sense. It means that basicaly replica for sysvol is located with a search frsReplicaSetType=2 right ? Matthieu. > > Thanks! > > Hongwei > > -Original Message- > From: Matthieu Patou [mailto:m...@samba.org] > Sent: Saturday, August 20, 2011 3:19 PM > To: Interoperability Documentation Help; p...@tridgell.net; > cifs-proto...@samba.org > Subject: Initial replication of sysvol through FRS > > Hello dochelp, > > I've got a question related to initial replication of sysvol, I've > noticed that if I join a W2K3 DC to a samba4 domain, where a samba4 DC > is already the FRS master and all LDAP entries related to FRS are > created, then the new DC will add entries in CN= object>,CN=File Replication Service,CN=System,DC=w2k,DC=domain,DC=tld > and under its own object (in OU=Domain > Controllers,DC=w2k,DC=domain,DC=tld, for instance under > CN=S1-W2K3R2,OU=Domain Controllers,DC=w2k,DC=domain,DC=tld). > > The question that I have is the following: given the fact that the > nTFRSReplicaSet object for sysvol replication can have a different > name than "Domain System Volume (SYSVOL share)", and given the fact > that fRSVersionGUID and fRSReplicaSetGUID are not used as indicated in > 2.3.1.2 NTFRS Replica Set Object and in behavior note<26> (about Section > 2.3.2.2), how a new DC locate the correct replica-set ? > > I somehow have the feeling that it will use frsReplicaSetGUID in order to > locate the correct replica. If not how ? > > Can you explain ? > > Thanks. > > Matthieu. > > > -- > Matthieu Patou > Samba Teamhttp://samba.org > Private repo http://git.samba.org/?p=mat/samba.git;a=summary > > > -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111082117135230] RE: Initial replication of sysvol through FRS
Hi Hongwei, On 30/08/2011 21:58, Hongwei Sun wrote: Matthieu, As per 2.3.2.2 MS-FRS1, A domain MUST have only one NTFRS replica set object of type SYSVOL. The fRSReplicaSetType attribute of a SYSVOL type object MUST be set to 2. Based on this, the FRS can go through all the NTFRS Replica Set Objects to find the correct replica set for SYSVOL. Please let me know if this makes sense. It means that basicaly replica for sysvol is located with a search frsReplicaSetType=2 right ? Matthieu. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Saturday, August 20, 2011 3:19 PM To: Interoperability Documentation Help; p...@tridgell.net; cifs-proto...@samba.org Subject: Initial replication of sysvol through FRS Hello dochelp, I've got a question related to initial replication of sysvol, I've noticed that if I join a W2K3 DC to a samba4 domain, where a samba4 DC is already the FRS master and all LDAP entries related to FRS are created, then the new DC will add entries in CN=,CN=File Replication Service,CN=System,DC=w2k,DC=domain,DC=tld and under its own object (in OU=Domain Controllers,DC=w2k,DC=domain,DC=tld, for instance under CN=S1-W2K3R2,OU=Domain Controllers,DC=w2k,DC=domain,DC=tld). The question that I have is the following: given the fact that the nTFRSReplicaSet object for sysvol replication can have a different name than "Domain System Volume (SYSVOL share)", and given the fact that fRSVersionGUID and fRSReplicaSetGUID are not used as indicated in 2.3.1.2 NTFRS Replica Set Object and in behavior note<26> (about Section 2.3.2.2), how a new DC locate the correct replica-set ? I somehow have the feeling that it will use frsReplicaSetGUID in order to locate the correct replica. If not how ? Can you explain ? Thanks. Matthieu. -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111081664438980] RE: Level 257 FindFirst rejected by some Windows servers even though NTLM
Steve, Any update ? Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Thursday, August 25, 2011 4:26 PM To: 'Steve French' Cc: Edgar Olougouna; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:111081664438980] RE: [cifs-protocol] Level 257 FindFirst rejected by some Windows servers even though NTLM Steve, What program or API are you using on Windows client to test FIND_FIRST2 command ?Have you observed that the same Windows client sends the different information level while connecting to different server ?The client (redirector) maps the application-provided [MS-FSCC] information levels to a SMB information Level.SMB_FIND_FILE_BOTH_DIRECTORY_INFO is mapped to FileBothDirectoryInformation passed from the application. I just want to check to see how this is passed from the application. Thanks! Hongwei -Original Message- From: Steve French [mailto:smfre...@gmail.com] Sent: Wednesday, August 24, 2011 4:23 PM To: Hongwei Sun Cc: Edgar Olougouna; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [REG:111081664438980] RE: [cifs-protocol] Level 257 FindFirst rejected by some Windows servers even though NTLM On Tue, Aug 23, 2011 at 10:43 PM, Hongwei Sun wrote: > Steve, > > Windows CE is not within the scope of protocol documentation, such as > MS-SMB and MS-CIFS. Therefore it is understandable that it doesn't behave > as specified in the protocol documents. This is more about what Windows clients do not about the WindowsCE server. Clearly windows clients works (to WindowsCE server) - and it appears it is because they choose levels carefully to avoid the WindowsCE server problems instead of FIND_FILE_DIRECTORY_INFO (level 257) nor FIND_FILE_FULL_DIRECTORY_INFO (258) nor FIND_FILE_ID_FULL_DIRECTORY_INFO (262) Windows clients (XP, Vista, etc) know enough to send SMB_FIND_FILE_BOTH_DIRECTORY_INFO (260) which doesn't make sense since FIND_FILE_BOTH_DIRECTORY_INFO requires the server to return the short name (which no longer seems relevant to windows clients but they are requesting it - even of WindowsCE). Windows is NOT returning operation not supported (or the eqiuvalent) to the application, rather it is selectively choosing to use level 260 (rather than the 3 other more logical find levels) So the question is - how does Windows (clients) determine which level to request on FindFirst - in particular when not to use 257, 258 or 262 and fall back to 260? > As far as Windows systems, as per 2.2.2.3.1 MS-CIFS, for Windows NT > and earlier, the Find information levels supported are clearly > specified > > SMB_INFO_STANDARD 0x0001 > (LANMAN2.0) > SMB_INFO_QUERY_EA_SIZE 0x0002 > (LANMAN2.0) > SMB_INFO_QUERY_EAS_FROM_LIST 0x0003 (LANMAN2.0) > SMB_FIND_FILE_DIRECTORY_INFO 0x0101 (NT LANMAN) > SMB_FIND_FILE_FULL_DIRECTORY_INFO 0x0102 (NT LANMAN) > SMB_FIND_FILE_NAMES_INFO 0x0103 (NT LANMAN) > SMB_FIND_FILE_BOTH_DIRECTORY_INFO 0x0104 (NT LANMAN) > > For Windows 2000 and later , in addition to the levels above , the > following levels are added as per MS-SMB 2.2.6.1.1 > > SMB_FIND_FILE_ID_FULL_DIRECTORY_INFO 0x0105 (NT LANMAN) > SMB_FIND_FILE_ID_BOTH_DIRECTORY_INFO 0x0106 (NT LANMAN) > > As per 2.2.8 MS-CIFS, The client MUST map the application-provided > [MS-FSCC] information levels to SMB information Levels. For all other > [MS-FSCC] information levels, the client MUST fail the request with > STATUS_NOT_SUPPORTED. In some case, the client MUST send a fixed level. > For example, a client that has not negotiated long names support MUST request > only SMB_INFO_STANDARD. > > Please let us know if you have more questions. > > Thanks! > > Hongwei > > > > > -Original Message- > From: cifs-protocol-boun...@cifs.org > [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Steve French > Sent: Thursday, August 18, 2011 4:54 PM > To: Edgar Olougouna > Cc: p...@tridgell.net; cifs-proto...@samba.org > Subject: Re: [cifs-protocol] Level 257 FindFirst rejected by some > Windows servers even though NTLM > > It looks like Windows CE takes (only?) level 260 but I can't easily prove it > without access to a test system (I just have some customer traces) - so how > does Windows clients (Windows XP/Vista/7 etc.) determine which FindFirst > level to send to these given that the Microsoft server in this case is > reporting NT Find and NT SMB support but in practice not supporting most > FindFirst levels. > > On Tue, Aug 16, 2011 at 12:56 PM, Edgar Olougouna > wrote: >> [Dochelp to bcc] >> >> Steve, >> >> One of our engineers will follow-up soon on this inquiry. The case number is >> 111081664438980. >> >> Regards, >> Edgar >> >> -Original Message- >> From: Steve French [mailto:smfre...@gmail.com] >> Sent: Tuesday, Augus
[cifs-protocol] [REG:111082117135230] RE: Initial replication of sysvol through FRS
Matthieu, As per 2.3.2.2 MS-FRS1, A domain MUST have only one NTFRS replica set object of type SYSVOL. The fRSReplicaSetType attribute of a SYSVOL type object MUST be set to 2. Based on this, the FRS can go through all the NTFRS Replica Set Objects to find the correct replica set for SYSVOL. Please let me know if this makes sense. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Saturday, August 20, 2011 3:19 PM To: Interoperability Documentation Help; p...@tridgell.net; cifs-proto...@samba.org Subject: Initial replication of sysvol through FRS Hello dochelp, I've got a question related to initial replication of sysvol, I've noticed that if I join a W2K3 DC to a samba4 domain, where a samba4 DC is already the FRS master and all LDAP entries related to FRS are created, then the new DC will add entries in CN=,CN=File Replication Service,CN=System,DC=w2k,DC=domain,DC=tld and under its own object (in OU=Domain Controllers,DC=w2k,DC=domain,DC=tld, for instance under CN=S1-W2K3R2,OU=Domain Controllers,DC=w2k,DC=domain,DC=tld). The question that I have is the following: given the fact that the nTFRSReplicaSet object for sysvol replication can have a different name than "Domain System Volume (SYSVOL share)", and given the fact that fRSVersionGUID and fRSReplicaSetGUID are not used as indicated in 2.3.1.2 NTFRS Replica Set Object and in behavior note <26> (about Section 2.3.2.2), how a new DC locate the correct replica-set ? I somehow have the feeling that it will use frsReplicaSetGUID in order to locate the correct replica. If not how ? Can you explain ? Thanks. Matthieu. -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:111082778570440] RE: precision about Parent GUID for FrsRpcStartPromotionParent
Matthieu, As per the existing documentation and my code review, the documentation in 3.3.4.2 MS-FRS1 is correct. This value is returned by the server as per section 3.3.4.2 and it is set to the GUID of local replica identified on the server by ReplicaSetName, which is one of the input parameters of the function. Please let me know if you have more questions about this issue. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Friday, August 26, 2011 6:45 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org Subject: precision about Parent GUID for FrsRpcStartPromotionParent Hello Dochelp, I'm trying to understand what "Parent GUID" is in paragraph 3.3.4.2 FrsRpcStartPromotionParent Message (Opnum 2), it is stated this "ParentGuid: GUID value that identifies the parent for the inbound connection." In my traces I have different values of GUID, for instance 013efea8---a8ff-3e01746cbc77, when I try to search all the DCs with something like that ./bin/ldbsearch -H ldap://172.16.101.29 -U administrator%totoTATA123 -b "" I have no results, so I tend to think that the parent is not an AD object is it a filesystem object ? Thanks for the info. Matthieu. -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB2 Request Response Ordering Guarantees.
I have some questions as to what the guarantees in the protocol are as far as "ordering" of responses and when those responses occurred. MS-SMB2: 3.1.5 is clear in that it says there is no processing or sequencing rules. (If this is the correct part of the document to draw such semantics from.) But it does not tell an implementer about the meaning of the responses. Do they have to be "temporally" correct. IE: If the server replies Q happened, all other responses there after should have Q taken into account. A paraphrased set of examples is included below, please read them for their intent not for full correctness. Example #1: Client: Compound: (CREATE REQUEST for directory X; QUERY_DIRECTORY REQUEST in directory X; QUERY_DIRECTORY request in directory X) Client :CREATE REQUEST for file Y in directory X (No permission for delete given) Server: CREATE REQUEST response for file Y (File is created.) Server: Compound (CREATE REQUEST response; QUERY_DIRECTORY REQUEST response (Does not contain file Y); QUERY_DIRECTORY response no more files) And how does that answer compare to: Example #2: Client :CREATE REQUEST for file Y in directory X (No permission for delete given) Server: CREATE REQUEST response for file Y (File is created.) Client: Compound: (CREATE REQUEST for directory X; QUERY_DIRECTORY REQUEST in directory X; QUERY_DIRECTORY request in directory X) Server: Compound (CREATE REQUEST response; QUERY_DIRECTORY REQUEST response (Does not contain file Y); QUERY_DIRECTORY Is the server correct to reply without Y, in any of the above cases? Why or why not? If the server is allowed to reply without Y in example #2, in a "strictly" conforming implementation, could QUERY_DIRECTORY always return the same list of entries that is cached, regardless of what the object store has in it. Why or why not? Thanks, -Ira ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 111081578094589] Explanation about the LZNT1 compression scheme in FRS1.
Matthieu, Yes, there will be an update to MS-FRS1. The product team is looking into the most appropriate way to reflect this in the document. In the "Lempel-Ziv Compression in Windows.pdf" document communicated in my previous email, there is a generic example on how to work out the Lempel-Ziv compression and decompression in Windows. Regards, Edgar -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Monday, August 29, 2011 6:11 PM To: Edgar Olougouna Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: [REG: 111081578094589] Explanation about the LZNT1 compression scheme in FRS1. Hi, Edgar, Can we expect some updates of FRS1 with for instance a example of the compressed and then uncompressed data ? Matthieu. On 29/08/2011 23:24, Edgar Olougouna wrote: > Matthieu, > > Your observation is correct. Windows implementation of the Lempel-Ziv > compression algorithm is based on the original algorithm in [UASDC]. However, > Windows modifies the basic algorithm as detailed in the attached document > "Lempel-Ziv Compression in Windows.pdf". > > [UASDC] Ziv, J. and Lempel, A., "A Universal Algorithm for Sequential Data > Compression", May 1977, http://ieeexplore.ieee.org/iel5/18/22696/01055714.pdf. > > Regards, > Edgar > > -Original Message- > From: Edgar Olougouna > Sent: Monday, August 22, 2011 7:34 PM > To: m...@samba.org > Cc: cifs-proto...@samba.org; p...@tridgell.net > Subject: RE: [REG: 111081578094589] Explanation about the LZNT1 compression > scheme in FRS1. > > Matthieu, > > We are actively working on this issue. I will update you as soon as we > complete our investigation. Thank you for your patience. > > Regards, > Edgar > > -Original Message- > From: Matthieu Patou > Sent: Monday, August 22, 2011 6:29 PM > To: Edgar Olougouna > Cc: cifs-proto...@samba.org; p...@tridgell.net > Subject: Re: [REG: 111081578094589] Explanation about the LZNT1 compression > scheme in FRS1. > > > Hi Edgar, > > Have you any news on this ? > > Thanks. > > Matthieu. > > On 17/08/2011 19:49, Edgar Olougouna wrote: >> [Adding case number in subject] >> >> Matthieu, >> >> I have taken ownership of this issue. I will update you as soon as we >> complete our investigation. >> >> Thanks, >> Edgar >> >> -Original Message- >> From: Edgar Olougouna >> Sent: Monday, August 15, 2011 4:44 PM >> To: m...@samba.org; cifs-proto...@samba.org; p...@tridgell.net >> Subject: RE: Explanation about the LZNT1 compression scheme in FRS1. >> >> [Dochelp to bcc] >> >> Matthieu, >> >> I have created the case number 111081578094589 to track this request. One of >> our team members will follow-up soon. >> >> Thanks, >> Edgar >> >> -Original Message- >> From: Matthieu Patou [mailto:m...@samba.org] >> Sent: Monday, August 15, 2011 4:22 PM >> To: Interoperability Documentation Help; cifs-proto...@samba.org; >> p...@tridgell.net >> Subject: Explanation about the LZNT1 compression scheme in FRS1. >> >> Hello, >> >> MS-FRS1.pdf indicate that LZNT1 compression is used and point to >> http://go.microsoft.com/fwlink/?LinkId=90549 for explanations. >> >> But this link only describe the Zif& Lampel method for loss-less >> compression. It seems that compressed data that comes after the STAGE_HEADER >> is mostly following this method but that there is some headers associated. >> >> If it's not an impression can it be documented, if it's just an impression >> can you show in the example like 4.4.7 PDC Sends Out CMD_RECEIVING_STAGE how >> to pass from the compressed content to the uncompressed content ? >> >> Thanks. >> >> Matthieu. >> >> >> -- >> Matthieu Patou >> Samba Teamhttp://samba.org >> Private repo http://git.samba.org/?p=mat/samba.git;a=summary >> >> >> >> > > -- > Matthieu Patou > Samba Teamhttp://samba.org > Private repo http://git.samba.org/?p=mat/samba.git;a=summary > > > -- Matthieu Patou Samba Teamhttp://samba.org Private repo http://git.samba.org/?p=mat/samba.git;a=summary ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Handling of passwords in LSA CreateTrustedDomainInfoEx2
Hi Andrew, thank you for your question. Someone from the Open Specifications team will respond to you soon. Josh Curry | Escalation Engineer | US-CSS Developer Support Core (DSC) Protocol Team P +1 469 775 7215 One Microsoft Way, 98052, Redmond, WA, USA http://support.microsoft.com -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, August 30, 2011 7:54 AM To: Interoperability Documentation Help Cc: cifs-protocol@cifs.org Subject: Handling of passwords in LSA CreateTrustedDomainInfoEx2 In CreateTrustedDomainInfoEx2 http://msdn.microsoft.com/en-us/library/cc234380%28v=PROT.13%29.aspx I'm wondering if I could get an expansion on: AuthenticationInformation: A structure containing authentication information for the trusted domain. The server first MUST decrypt this data structure using an algorithm (as specified in section 5.1.1) with the key being the session key negotiated by the transport. The server then MUST unmarshal the data inside this structure and then store it into a structure whose format is specified in section 2.2.7.11. This structure MUST then be stored on Trust Incoming and Outgoing Password properties. In particular, what elements become assigned to "trustAuthIncoming" and "trustAuthOutgoing" Is the element stored 'as sent', or is it processed to add a version field? Can the client send the previousAuthentication details, or is that maintained by the server? In LsarSetInformationTrustedDomain http://msdn.microsoft.com/en-us/library/cc234385%28v=PROT.13%29.aspx Does the client or the server maintain the previous password and version information in the blob in the "trustAuthIncoming"? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Handling of passwords in LSA CreateTrustedDomainInfoEx2
In CreateTrustedDomainInfoEx2 http://msdn.microsoft.com/en-us/library/cc234380%28v=PROT.13%29.aspx I'm wondering if I could get an expansion on: AuthenticationInformation: A structure containing authentication information for the trusted domain. The server first MUST decrypt this data structure using an algorithm (as specified in section 5.1.1) with the key being the session key negotiated by the transport. The server then MUST unmarshal the data inside this structure and then store it into a structure whose format is specified in section 2.2.7.11. This structure MUST then be stored on Trust Incoming and Outgoing Password properties. In particular, what elements become assigned to "trustAuthIncoming" and "trustAuthOutgoing" Is the element stored 'as sent', or is it processed to add a version field? Can the client send the previousAuthentication details, or is that maintained by the server? In LsarSetInformationTrustedDomain http://msdn.microsoft.com/en-us/library/cc234385%28v=PROT.13%29.aspx Does the client or the server maintain the previous password and version information in the blob in the "trustAuthIncoming"? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
