Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

2010-01-25 Thread Bill Wesse
Good morning Matthieu. Thanks for your patience. Our documentation team has 
responded to 3 of the four cross-reference requests. Details are shown below, 
as well as an attached pdf ([MS-ADTS]_Changes.pdf) showing new text for that 
document.

1. A request was made for a link in '[MS-ADTS] section 7.1.6.7.3 
msDs-supportedEncryptionTypes', pointing to '[MS-LSAD] section 2.2.7.18 
TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES'.

We haven't added this link because the relationship between the 
trustedDomain!msDs-supportedEncryptionTypes attribute and 
TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES structure is already specified in 
'[MS-LSAD] section 3.1.1.5 Trusted Domain Object Data Model'.

2. A request was made for a link in '[MS-ADTS] section 7.1.6.7.3 
msDs-supportedEncryptionTypes', pointing to '[MS-NRPC] section 2.2.1.3.11 
NETLOGON_DOMAIN_INFO (SupportedEncTypes)'.

We haven't added this link, because we think this link would be inappropriate, 
since these two sections are about two different types of object. '[MS-ADTS] 
section 7.1.6.7.3 msDs-supportedEncryptionTypes' is about trustedDomain 
objects; however, the NETLOGON_DOMAIN_INFO structure in '[MS-NRPC] section 
2.2.1.3.11 NETLOGON_DOMAIN_INFO' provides information on a domain joined 
computer object.

Therefore, instead of adding a cross reference between 
trustedDomain!msDs-supportedEncryptionTypes and NETLOGON_DOMAIN_INFO, we have 
added text in the [MS-ADTS] sections noted below providing information on the 
msDs-supportedEncryptionTypes attribute of the computer object.

[MS-ADTS] 7.4.1 State of a Machine Joined to a Domain
[MS-ADTS] 7.4.2 State in an Active Directory Domain
[MS-ADTS] 7.4.3 Relationship to Protocols

3. A request was made for links in '[MS-LSAD] section 2.2.7.18 
TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES', pointing to '[MS-ADTS] 7.1.6.7.3 
msDs-supportedEncryptionTypes' and '[MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO' 
(SupportedEncTypes).

We haven't added these links, because when describing the member 
SupportedEncTypes of struct NETLOGON_DOMAIN_INFO, '[MS-NRPC] section 2.2.1.3.11 
NETLOGON_DOMAIN_INFO' links to section '[MS-LSAD] 2.2.7.18 
TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES', which describes the structure 
represented in SupportedEncTypes. Additionally '[MS-LSAD] section 3.1.1.5 
Trusted Domain Object Data Model' references '[MS-ADTS] section 7.1.6.7.3 
msDs-supportedEncryptionTypes' to link the data retrieved from AD.

Also, [MS-LSAD] does not need to reference [MS-NRPC] for the purposes of 
supported encryption types because MS-LSAD does not consume any encryption type 
definition in [MS-NRPC].

Additionally, [MS-LSAD] supportedEncryptionTypes usage is for trusts only, 
whereas [MS-NRPC] supportedEncryptionTypes usage is for both trusts and 
computers.

4. A request was made for links in '[MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO 
(SupportedEncTypes)', pointing to '[MS-ADTS] 7.1.6.7.3 
msDs-supportedEncryptionTypes'.

This request is currently pending review.

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

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


Re: [cifs-protocol] Conflicting OIDs

2010-01-25 Thread Edgar Olougouna
Andrew,



Thank you for bringing these OID conflicts to our attention.



The following table summarizes the known list of OIDs that Microsoft uses in 
Active Directory that have conflicting allocations between AD and either the 
OID allocation hierarchy.



Name in AD


OID in MS-ADA*


Organization


Name registered


OID (if different from AD)


middleName


2.16.840.1.113730.3.1.34


Netscape


ref





thumbnailLogo


2.16.840.1.113730.3.1.36


Netscape


nsLicensedFor





thumbnailPhoto


2.16.840.1.113730.3.1.35


Netscape


changeLog





userSMIMECertificate


2.16.840.1.113730.3.140


Netscape


userSMIMECertificate


2.16.840.1.113730.3.1.40




Our assignment of these OIDs has been around since AD inception in Windows 
Server 2000. It would not feasible to retroactively change the OIDs due to the 
resulting compatibility issues. As a result, the OIDs provided in the protocol 
documents do accurately describe system behaviors and are sufficient to 
facilitate development of compatible implementations.



In retrospective, the product team has recognized the need for a change in the 
process for allocating OIDs and avoiding conflicts in the future and has the 
necessary processes in place to avoid further occurrences.



Best regards,

Edgar





-Original Message-
From: Edgar Olougouna
Sent: Wednesday, December 09, 2009 11:35 AM
To: Andrew Bartlett
Cc: cifs-proto...@samba.org; p...@tridgell.net; Endi Sukma Dewata
Subject: RE: Conflicting OIDs



Andrew,



I am taking care of this and will be updating you as soon as I have news.



Best regards,



Edgar





-Original Message-

From: Bill Wesse

Sent: Wednesday, December 09, 2009 7:51 AM

To: Andrew Bartlett; Interoperability Documentation Help

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

Subject: RE: Conflicting OIDs



Good morning Andrew - thanks for your question - I have created the below case 
for us to track our efforts regarding that. One of my colleagues will take 
ownership and contact you shortly.



SRX091209600017 : [MS-ADA3] Conflicting OIDs



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: Andrew Bartlett [mailto:abart...@samba.org]

Sent: Tuesday, December 08, 2009 8:44 PM

To: Interoperability Documentation Help

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

Subject: Conflicting OIDs



MS-ADA3 2.305 Attribute thumbnailLogo has:



cn: Logo

ldapDisplayName: thumbnailLogo

attributeId: 2.16.840.1.113730.3.1.36



However, this OID is allocated, according to 
http://www.alvestrand.no/objectid/2.16.840.1.113730.3.1.36.html to Netscape 
(now Red Hat), and is used for nsLicensedFor.



It appears the official OID for thumbnailLogo is

1.3.6.1.4.1.1466.101.120.36 according to



http://tools.ietf.org/html/draft-ietf-asid-schema-pilot-00





So far, we have found the following OIDs that are allocated to different names 
between Microsoft's AD implementation and the official

allocations:



#MiddleName has a conflicting OID

2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1

#defaultGroup has a conflicting OID

1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2

#thumbnailPhoto has a conflicting OID

2.16.840.1.113730.3.1.35:1.3.6.1.4.1.7165.4.255.10

#thumbnailLogo has a conflicting OID

2.16.840.1.113730.3.1.36:1.3.6.1.4.1.7165.4.255.11



What I want to know is:  What is the full list of OIDs that Microsoft uses in 
Active Directory that have conflicting allocations between AD and either the 
OID allocation hierarchy or common practice?



This will assist us as we aim for interoperability, as for each conflict, we 
must manually remap.



In the long term, we would like to see the AD schema documents annotated with 
this conflict (both as as summary table and on each attribute), and a process 
put in place to avoid these kinds of problems in future.



Thanks,



Andrew Bartlett



--

Andrew Bartletthttp://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