From garming at catalyst.net.nz Sun Aug 5 23:46:47 2018 From: garming at catalyst.net.nz (Garming Sam) Date: Mon, 6 Aug 2018 11:46:47 +1200 Subject: [cifs-protocol] GptTmpl.inf syntax documentation issues in MS-GPSB [REG:118052218237829] In-Reply-To: References: Message-ID: <44ba2667-af5c-2075-cb9f-0cf8307e6d8d@catalyst.net.nz> Hi, Just been on leave. Yes that looks much better. Thanks for the help. Cheers, Garming On 27/06/18 08:24, Jeff McCashland wrote: > [-casemail] > > Hi Garming, > > We have updated [MS-GPSB] for the next release with the following changes: > > MS Response 6/25/2018 > TDI 8624 has been addressed in MS-GPSB. These changes are available in the daily build of 6/25/2018. > > Section 2.2 Message Syntax > > Revised syntax from: > InfFile = UnicodePreamble VersionPreamble Sections > UnicodePreamble = *("[Unicode]" LineBreak "Unicode=yes" > LineBreak) > VersionPreamble = "[Version]" LineBreak "signature=" > DQUOTE "$CHICAGO$" DQUOTE LineBreak "Revision=1" LineBreak > Sections = Section / Section Sections > Section = Header Settings > Header = "[" HeaderValue "]" LineBreak > HeaderValue = StringWithSpaces > Settings = Setting / Setting Settings > Setting = Key Wsp "=" Wsp ValueList LineBreak / > ValueList = Value / Value Wsp "," Wsp ValueList > Key = String > Value = String / QuotedString > > To: > InfFile = UnicodePreamble VersionPreamble Sections > UnicodePreamble = *("[Unicode]" LineBreak "Unicode=yes" > LineBreak) > VersionPreamble = "[Version]" LineBreak "signature=" > DQUOTE "$CHICAGO$" DQUOTE LineBreak "Revision=1" LineBreak > Sections = Section / Section Sections > Section = Header Settings > Header = "[" HeaderValue "]" LineBreak > HeaderValue = StringWithSpaces > Settings = Setting / Setting Settings > Setting = Key Wsp "=" Wsp ValueList LineBreak / > Name "," Mode "," AclString LineBreak > Name = String / QuotedString > Mode = [0-9]+ > AclString = SDDL / DQUOTE SDDL DQUOTE > ValueList = Value / Value Wsp "," Wsp ValueList > Key = String > Value = String / QuotedString > > Changed Service General Settings to Service General Setting. > > Section 2.2.8 Service General Setting > Changed title from plural (Settings) to singular > > Revised syntax order from: > Header = "[" HeaderValue "]" LineBreak > HeaderValue = "Service General Setting" > Settings = Setting / Setting Settings > ServiceName = 1*256IdCharacter / DQUOTE 1*256IdCharacter DQUOTE > IdCharacter = ALPHANUM/ %d33 / %d35-43 / %d45-46 / %d58-64 / %d91 / %d93-96 / %d123-126 > Setting = ServiceName "," StartupMode "," AclString LineBreak > StartupMode = DIGIT > AclString = SDDL / DQUOTE SDDL DQUOTE > > To: > Header = "[" HeaderValue "]" LineBreak > HeaderValue = "Service General Setting" > Settings = Setting / Setting Settings > Setting = ServiceName "," StartupMode "," AclString LineBreak > ServiceName = 1*256IdCharacter / DQUOTE 1*256IdCharacter DQUOTE > IdCharacter = ALPHANUM/ %d33 / %d35-43 / %d45-46 / %d58-64 / %d91 / %d93-96 / %d123-126 > StartupMode = DIGIT > AclString = SDDL / DQUOTE SDDL DQUOTE > > Section 3.2.5.10 Service General Setting > Changed plural "Service General Settings" to singular "Service General Setting" throughout. > > Hope that helps! > > Best regards, > Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) > Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 > We value your feedback.  My manager is Rama Ganesan (ramagane), +1 (425) 703-8712 > > -----Original Message----- > From: Jeff McCashland > Sent: Friday, June 01, 2018 1:34 PM > To: Garming Sam > Cc: cifs-protocol at lists.samba.org; MSSolve Case Email > Subject: RE: GptTmpl.inf syntax documentation issues in MS-GPSB [REG:118052218237829] > > Hi Garming, > > I've verified that the general syntax description does not cover the three sub-sections exactly as you say. Thank you for reporting this issue. I will file a change request to update our documentation. > > Best regards, > Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team > > -----Original Message----- > From: Jeff McCashland > Sent: Tuesday, May 22, 2018 4:39 PM > To: Garming Sam > Cc: cifs-protocol at lists.samba.org; MSSolve Case Email > Subject: RE: GptTmpl.inf syntax documentation issues in MS-GPSB [REG:118052218237829] > > Thanks, Tom! [Tom to BCC] > > Hi Garming, > > I will be assisting you with this issue. Let me do some research on the INF syntax, and I will let you know what I find. > > Best regards, > Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 We value your feedback.  My manager is Rama Ganesan (ramagane), +1 (425) 703-8712 > > -----Original Message----- > From: Tom Jebo > Sent: Tuesday, May 22, 2018 4:06 PM > To: Garming Sam > Cc: cifs-protocol at lists.samba.org; MSSolve Case Email > Subject: RE: GptTmpl.inf syntax documentation issues in MS-GPSB [REG:118052218237829] > > [dochelp to bcc] > [casemail to cc] > > Hi Garming, > > Thank you for reaching out to dochelp about this issue. One of the Open Specifications team members will be responding shortly to assist you with this. > In the meantime, I've created a case and added the number (118052218237829) to the subject. Please keep the number in the subject and refer to this when corresponding to us about this issue. > > Best regards, > Tom Jebo > Sr Escalation Engineer > Microsoft Open Specifications > > -----Original Message----- > From: Garming Sam > Sent: Tuesday, May 22, 2018 3:38 PM > To: Interoperability Documentation Help > Cc: cifs-protocol at lists.samba.org > Subject: GptTmpl.inf syntax documentation issues in MS-GPSB > > Hi, > > In section 2.2 of MS-GPSB, it lists "Service General Settings" as a possible HeaderValue, when upon looking at 2.2.8 Service General Settings, it should be "Service General Setting" without the additional 's'. > > Looking more closely at section 2.2.8, you also find that the ABNF description of the .inf file in 2.2 appears incomplete. In section 2.2, it would appear that all settings are in the form 'key = value'. Section > 2.2.8 (2.2.7 and also 2.2.9) describe an alternate format which is stored 'name,mode,ACL' where there is no '=' in the line at all. > > Examples generated from Windows: > > [Service General Setting] > "Dhcp",3,"" > > [Registry Keys] > "MACHINE\SOFTWARE\Microsoft\TelnetServer\Defaults",0,"D:PAR(A;CI;KA;;;BA)(A;CIIO;KA;;;CO)(A;CI;KA;;;SY)(A;CI;KR;;;BU)(A;CI;KR;;;S-1-15-2-1)" > > For the top-level description to be generally correct, I would've expected a syntax more like the following: > > Settings = Settings / Setting Settings > Setting = Key Wsp "=" Wsp ValueList LineBreak / Name "," Mode "," > AclString LineBreak > > Name = String / QuotedString > Mode = [0-9]+ > AclString = SDDL / DQUOTE SDDL DQUOTE > > > Cheers, > > Garming > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstephen at redhat.com Thu Aug 23 19:06:15 2018 From: jstephen at redhat.com (Justin Stephenson) Date: Thu, 23 Aug 2018 15:06:15 -0400 Subject: [cifs-protocol] MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection Message-ID: Hello, I would like to ask for clarification on the rejection criteria used for the client information fields provided in the RpcAsyncOpenPrinter method, and specifically the dwBuildNum value. Testing against Windows Server 2016 this RpcAsyncOpenPrinter method returns Access Denied when SPL_CLIENT_INFO buildnum value, as part of pClientInfo, is a value less than 6000(Windows Vista and Windows Server 2008). Higher advertised OS values greater than 6000 successfully open a printer handle. I have attached working and non-working packet captures taken for evidence of this with the build number used in the filename. The following statement on MS-RPRN page 396/415 seems incorrect, or requires further clarification. *Windows does not use the following members: pUserName,dwBuildNum, dwMajorVersion, dwMinorVersion, and wProcessorArchitecture.* Thank you. Kind regards, Justin Stephenson -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: captures.tar.gz Type: application/gzip Size: 217740 bytes Desc: not available URL: From obaidf at microsoft.com Thu Aug 23 19:34:26 2018 From: obaidf at microsoft.com (Obaid Farooqi) Date: Thu, 23 Aug 2018 19:34:26 +0000 Subject: [cifs-protocol] MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection [118082318853387] Message-ID: Hi Justin: Thanks for contacting Microsoft. I have created a case to track this issue. A member of The Open Specifications Team will be in touch soon. Regards, Obaid Farooqi Escalation Engineer | Microsoft From: Justin Stephenson Sent: Thursday, August 23, 2018 2:06 PM To: Interoperability Documentation Help Cc: cifs-protocol at lists.samba.org Subject: MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection Hello, I would like to ask for clarification on the rejection criteria used for the client information fields provided in the RpcAsyncOpenPrinter method, and specifically the dwBuildNum value. Testing against Windows Server 2016 this RpcAsyncOpenPrinter method returns Access Denied when SPL_CLIENT_INFO buildnum value, as part of pClientInfo, is a value less than 6000(Windows Vista and Windows Server 2008). Higher advertised OS values greater than 6000 successfully open a printer handle. I have attached working and non-working packet captures taken for evidence of this with the build number used in the filename. The following statement on MS-RPRN page 396/415 seems incorrect, or requires further clarification. Windows does not use the following members: pUserName, dwBuildNum, dwMajorVersion, dwMinorVersion, and wProcessorArchitecture. Thank you. Kind regards, Justin Stephenson -------------- next part -------------- An HTML attachment was scrubbed... URL: From edgaro at microsoft.com Thu Aug 23 21:27:34 2018 From: edgaro at microsoft.com (Edgar Olougouna) Date: Thu, 23 Aug 2018 21:27:34 +0000 Subject: [cifs-protocol] MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection [118082318853387] In-Reply-To: References: Message-ID: Justin, I will review this and follow-up soon. Thanks, Edgar From: Obaid Farooqi Sent: Thursday, August 23, 2018 2:34 PM To: Justin Stephenson Cc: cifs-protocol at lists.samba.org; MSSolve Case Email Subject: RE: MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection [118082318853387] Hi Justin: Thanks for contacting Microsoft. I have created a case to track this issue. A member of The Open Specifications Team will be in touch soon. Regards, Obaid Farooqi Escalation Engineer | Microsoft From: Justin Stephenson > Sent: Thursday, August 23, 2018 2:06 PM To: Interoperability Documentation Help > Cc: cifs-protocol at lists.samba.org Subject: MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection Hello, I would like to ask for clarification on the rejection criteria used for the client information fields provided in the RpcAsyncOpenPrinter method, and specifically the dwBuildNum value. Testing against Windows Server 2016 this RpcAsyncOpenPrinter method returns Access Denied when SPL_CLIENT_INFO buildnum value, as part of pClientInfo, is a value less than 6000(Windows Vista and Windows Server 2008). Higher advertised OS values greater than 6000 successfully open a printer handle. I have attached working and non-working packet captures taken for evidence of this with the build number used in the filename. The following statement on MS-RPRN page 396/415 seems incorrect, or requires further clarification. Windows does not use the following members: pUserName, dwBuildNum, dwMajorVersion, dwMinorVersion, and wProcessorArchitecture. Thank you. Kind regards, Justin Stephenson -------------- next part -------------- An HTML attachment was scrubbed... URL: From edgaro at microsoft.com Fri Aug 31 04:23:50 2018 From: edgaro at microsoft.com (Edgar Olougouna) Date: Fri, 31 Aug 2018 04:23:50 +0000 Subject: [cifs-protocol] MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection [118082318853387] In-Reply-To: References: Message-ID: Justin, From what I see in the source code, it’s supposed to deny connection to open a printer connection from any client that has a build less than Vista RTM, e.g. dwBuildNum less than 6000. The error code is ERROR_ACCESS_DENIED. Setting the dwBuildNum to zero would bypass this validation check. I have opened a document bug and ask the product groups to amend the specifications. Let me know whether you have any additional question. Thanks, Edgar From: Edgar Olougouna Sent: Thursday, August 23, 2018 4:28 PM To: Justin Stephenson Cc: cifs-protocol at lists.samba.org; MSSolve Case Email Subject: RE: MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection [118082318853387] Justin, I will review this and follow-up soon. Thanks, Edgar From: Obaid Farooqi Sent: Thursday, August 23, 2018 2:34 PM To: Justin Stephenson > Cc: cifs-protocol at lists.samba.org; MSSolve Case Email > Subject: RE: MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection [118082318853387] Hi Justin: Thanks for contacting Microsoft. I have created a case to track this issue. A member of The Open Specifications Team will be in touch soon. Regards, Obaid Farooqi Escalation Engineer | Microsoft From: Justin Stephenson > Sent: Thursday, August 23, 2018 2:06 PM To: Interoperability Documentation Help > Cc: cifs-protocol at lists.samba.org Subject: MS-PAR and MS-RPRN Issue with SPLCLIENT_INFO Bulid number rejection Hello, I would like to ask for clarification on the rejection criteria used for the client information fields provided in the RpcAsyncOpenPrinter method, and specifically the dwBuildNum value. Testing against Windows Server 2016 this RpcAsyncOpenPrinter method returns Access Denied when SPL_CLIENT_INFO buildnum value, as part of pClientInfo, is a value less than 6000(Windows Vista and Windows Server 2008). Higher advertised OS values greater than 6000 successfully open a printer handle. I have attached working and non-working packet captures taken for evidence of this with the build number used in the filename. The following statement on MS-RPRN page 396/415 seems incorrect, or requires further clarification. Windows does not use the following members: pUserName, dwBuildNum, dwMajorVersion, dwMinorVersion, and wProcessorArchitecture. Thank you. Kind regards, Justin Stephenson -------------- next part -------------- An HTML attachment was scrubbed... URL: