[PATCH 4/5] s3-rpc: add server support for mgmt_inq_princ_name

[David Disseldorp]

On Thu, 16 Jan 2014 07:59:53 +1300
Andrew Bartlett <abartlet at samba.org> wrote:

> > > > +	/* MS-RPCE 2.2.1.1.7 Security Providers */
> > > > +	const uint32 MGMT_AUTHN_NONE = 0x00;
> > > > +	const uint32 MGMT_AUTHN_GSS_NEG = 0x09;
> > > > +	const uint32 MGMT_AUTHN_WINNT = 0x0A;
> > > > +	const uint32 MGMT_AUTHN_GSS_SCHANNEL = 0x0E;
> > > > +	const uint32 MGMT_AUTHN_GSS_KERBEROS = 0x10;
> > > > +	const uint32 MGMT_AUTHN_NETLOGON = 0x44;
> > > > +	const uint32 MGMT_AUTHN_DEFAULT = 0xFF;  
> > > 
> > > Can you reuse the DCERPC_AUTH_TYPE_* values from dcerpc.idl?  
> > 
> > There's some overlap with these values, but the mapping doesn't appear
> > to be consistent. I'd prefer to use the definitions above as they are
> > in MS-RPCE 2.2.1.1.7.  
> 
> What exactly are the differences?  I'm very cautious about this kind of
> duplication, my experience in the auth area is that this stuff really is
> defined only once, and that what we have seen as differences turns out
> to be misunderstandings or an incomplete view.  

  DCERPC_AUTH_TYPE_NONE     = 0,
Same.

  DCERPC_AUTH_TYPE_KRB5_1   = 1,
Not defined in MS-RPCE 2.2.1.1.7.

  DCERPC_AUTH_TYPE_SPNEGO   = 9,
Referred to as AUTHN_GSS_NEG.

  DCERPC_AUTH_TYPE_NTLMSSP  = 10,
Referred to as AUTHN_WINNT.

MS-RPCE 2.2.1.1.7 defines an AUTHN_GSS_SCHANNEL type here (0x0E).

  DCERPC_AUTH_TYPE_KRB5     = 16,
Same (AUTHN_GSS_KERBEROS).

  DCERPC_AUTH_TYPE_DPA      = 17,
  DCERPC_AUTH_TYPE_MSN      = 18,
  DCERPC_AUTH_TYPE_DIGEST   = 21,
Not defined.

  DCERPC_AUTH_TYPE_SCHANNEL = 68,
Referred to as AUTHN_NETLOGON

  DCERPC_AUTH_TYPE_MSMQ     = 100,
Not defined.

  DCERPC_AUTH_TYPE_NCALRPC_AS_SYSTEM = 200
Not defined.

MS-RPCE 2.2.1.1.7 defines an AUTHN_DEFAULT type here (0xFF) which is
to be translated on the client side to AUTHN_WINNT.

0x09, 0x0A and 0x10 appear to be the only values handled by the mgmt RPC
server, which can be mapped to the DCERPC_AUTH_TYPE_* values. On the
client side AUTHN_DEFAULT (0xFF) would be needed.

Do you really feel strongly about this, or can I continue to use the
values from the spec?

Cheers, David