[cifs-protocol] RE: KVNO of trusts

[Andrew Bartlett]

On Wed, 2008-10-08 at 09:31 -0700, John Dunning wrote:
> Hello Andrew,
>Thank you for your rewording suggestion. I have passed this information on 
> to my Product Team.
> 
> I also have an answer to your question:
> 
> "What is the kvno if the client does not provide one in that structure, when 
> it initially calls CreateTrustedDomainEx?  (I think it is -1)?"
> 
> Answer:
> 
> If TRUST_AUTH_TYPE_VERSION  is missing, the key version # for that
> trust key in Kerberos protocol is not filled. In such a case, the
> Windows Kerberos will ignore the missing key version # field.
> The key version (and the TRUST_AUTH_TYPE_VERSION field) is always
> present in Microsoft implementations to maximize interoperability.

I didn't find the version in the blob attached to the
CreateTrustedDomainEx2 call I got from Windows 2008.  That is why I
asked. 

Perhaps I'm (as a server) meant to add this to the record?  If so, what
information should I use to do so?

Also, while this element is indeed optional according to the ASN.1, it
seemed to be filled in by windows in this case.  

I'll try to reproduce the setup we had at the IO lab this week, and give
you some more concrete details. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org
Samba Developer, Red Hat Inc.  http://redhat.com



signature.asc
Description: This is a digitally signed message part
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[cifs-protocol] RE: Resend: Response: SRX080909600334: [MS-APDS] Backing store and policy application information

[Andrew Bartlett]

On Wed, 2008-10-08 at 08:09 -0700, Bill Wesse wrote:
> Good morning again Andrew! I am resending this since I have not
> received a response to my email of Sept 26. Could you advise me
> concerning how you would like the document to read?

> 
> Good morning Andrew. I have completed my preliminary investigation
> concerning your questions about password policy, validation and
> concrete backing store for user and trust account attributes.

I'm so sorry I didn't get back to you.  As I said to everyone else (at
the interop and SNIA events), I just wish the rest of the documentation
was so clear and provided such a useful mapping.  

Very well done!

Now, what is the long-term status of this document, and how can we make
it a modal for other protocols?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org
Samba Developer, Red Hat Inc.


signature.asc
Description: This is a digitally signed message part
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[cifs-protocol] RE: What are the 'Service' levels in SamLogonEx?

[Obaid Farooqi]

Andrew:
The person on the dev team wants to talk to you to answer these questions. Let 
me know when can I call you and at what number.

Thanks
Obaid

-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2008 6:13 PM
To: Obaid Farooqi
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: What are the 'Service' levels in SamLogonEx?

On Mon, 2008-10-06 at 16:03 -0700, Obaid Farooqi wrote:
> Good Afternoon Andrew:
>
> We have complete our investigation regarding
> NetlogonServiceInformation.
>
> NetlogonServiceInformation and thus
> NetlogonServiceTransitiveInformation are not used by any Windows
> protocol client. We will be removing all references to that logon type
> from the MS-NRPC TD. Thank you for bringing this issue to our
> attention.

So these are local-only operations, or what was their original purpose?

Also, the question of windows clients is only half the puzzle - do windows 
servers implement these levels to remote clients?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] preliminary UNIX extensions documentation

[Jeremy Allison]

On Wed, Oct 08, 2008 at 09:33:14AM -0700, James Peach wrote:
> Hi all,
>
> I had some time a couple of months ago, so I knocked up some  
> documentation for the UNIX extensions.
>
> Although what follows is in RFC format, I doubt that I will get around  
> to submitting this as a real IETF informational RFC. If someone else  
> wants to do that, I'll happily support that effort.
>
> I haven't documented all the UNIX extensions. I have documented all the 
> extensions used by the Mac OS X 10.5 SMB client, however. I'm happy to 
> take patches :)
>
> This documentation is licensed under the Common Documentation License,  
> .

Yay ! James, this is *great* ! I'll try and send patches
to add the other stuff. Well done, and thanks a *lot* for
taking the time to do this.

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

[cifs-protocol] preliminary UNIX extensions documentation

[James Peach]

Hi all,

I had some time a couple of months ago, so I knocked up some  
documentation for the UNIX extensions.


Although what follows is in RFC format, I doubt that I will get around  
to submitting this as a real IETF informational RFC. If someone else  
wants to do that, I'll happily support that effort.


I haven't documented all the UNIX extensions. I have documented all  
the extensions used by the Mac OS X 10.5 SMB client, however. I'm  
happy to take patches :)


This documentation is licensed under the Common Documentation License,  
.


cheers,
James

Network Working Group   J. Peach
Internet-Draft Apple Inc
Intended status: Informational  May 2008
Expires: November 2, 2008


   SMB Protocol Extensions for UNIX systems.
  draft-jpeach-smb-unix-extensions-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six  
months

   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 2, 2008.

Abstract

   This document describes various SMB protocol extensions that have
   been developed to more accurately express the filesystem semantics  
of

   UNIX-like systems.












Peach   Expires November 2, 2008[Page 1]
Internet-Draft SMB UNIX Extensions  May 2008


Table of Contents

   1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 1.1.  Requirements  
Language  . . . . . . . . . . . . . . . . . .  3
 1.2.   
Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
 1.3.  Protocol Extension  
Principles  . . . . . . . . . . . . . .  3
   2.  The UNIX Trans2 Command  
Space  . . . . . . . . . . . . . . . .  4
   3.  UNIX Capabilities  
Negotiation  . . . . . . . . . . . . . . . .  4
   4.  Filesystem  
Operations  . . . . . . . . . . . . . . . . . . . .  5
 4.1.   
SMB_QUERY_CIFS_UNIX_INFO . . . . . . . . . . . . . . . . .  6
 4.2.   
SMB_SET_CIFS_UNIX_INFO . . . . . . . . . . . . . . . . . .  6
 4.3.   
SMB_QUERY_POSIX_FS_INFO  . . . . . . . . . . . . . . . . .  7
 4.4.   
SMB_QUERY_POSIX_WHOAMI . . . . . . . . . . . . . . . . . .  7
   5.  File and Directory  
Operations  . . . . . . . . . . . . . . . .  9
 5.1.  POSIX Pathnames  . . . . . . . . . . . . . . . . . . . . .  
10
 5.2.  SMB_POSIX_PATH_OPEN  . . . . . . . . . . . . . . . . . . .  
10
 5.3.  QUERY_FILE_UNIX_LINK . . . . . . . . . . . . . . . . . . .  
12
 5.4.  SMB_POSIX_PATH_UNLINK  . . . . . . . . . . . . . . . . . .  
12
 5.5.  QUERY_POSIX_ACL  . . . . . . . . . . . . . . . . . . . . .  
13
 5.6.  QUERY_FILE_UNIX_BASIC  . . . . . . . . . . . . . . . . . .  
13
 5.7.  SMB_QUERY_FILE_UNIX_INFO2  . . . . . . . . . . . . . . . .  
14
 5.8.  SMB_QUERY_POSIX_LOCK . . . . . . . . . . . . . . . . . . .  
17
 5.9.  SMB_SET_POSIX_LOCK . . . . . . . . . . . . . . . . . . . .  
17
 5.10. Minshall+French Symlinks . . . . . . . . . . . . . . . . .  
17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  
18
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  
18
 7.1.  Normative References . . . . . . . . . . . . . . . . . . .  
18
 7.2.  Informative References . . . . . . . . . . . . . . . . . .  
18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  
19
   Intellectual Property and Copyright Statements . . . . . . . . . .  
20






















Peach   Expires November 2, 2008[Page 2]
Internet-Draft SMB UNIX Extensions  May 2008


1.  Introduction

   The SMB UNIX extensions were first developed by SCO and HP between
   1999 and 2001.  They were documented in the SNIA reference [SNIA] as
   a minimal set of UNIX-style operations.

   From 2004 to 2007, various new extensions were proposed and
   implemented as a response to the needs of SMB client authors who  
were

   i

[cifs-protocol] RE: KVNO of trusts

[John Dunning]

Hello Andrew,
   Thank you for your rewording suggestion. I have passed this information on 
to my Product Team.

I also have an answer to your question:

"What is the kvno if the client does not provide one in that structure, when it 
initially calls CreateTrustedDomainEx?  (I think it is -1)?"

Answer:

If TRUST_AUTH_TYPE_VERSION  is missing, the key version # for that trust key in 
Kerberos protocol is not filled. In such a case, the Windows Kerberos will 
ignore the missing key version # field.
The key version (and the TRUST_AUTH_TYPE_VERSION field) is always present in 
Microsoft implementations to maximize interoperability.

Please let me know if this fully answers this question.


Thanks
John Dunning
Senior Escalation Engineer Microsoft Corporation
US-CSS DSC PROTOCOL TEAM
Email: [EMAIL PROTECTED]
Tele: (469)775-7008

-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2008 12:04 PM
To: John Dunning
Cc: Interoperability Documentation Help; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: KVNO of trusts

On Thu, 2008-10-02 at 09:17 -0700, John Dunning wrote:
> Hello Andrew,
>
> We have concluded our investigation regarding this issue.
>
> Question: "How do I determine what Key Version Number (kvno) to assign to 
> trusted domain entities in the KDC?"
>
> Answer:
> The key version number of the trust password for a trust object is set
> by  making a LsarSetTrustedDomainInfoByName ([MS-LSAD] section
> 3.1.4.7.6)  request when the trust is created. It is incremented by 1
> each time the trust password is changed. The key version number can be
> determined at any time by making an LsarQueryTrustedDomainInfoByName
> request or parsing the trustAuthInfoIncoming/trustAuthInfoOutgoing
> attributes  using the information provided in MS-ADTS section
> 7.1.6.9.1 and looking for an LSAPR_AUTH_INFORMATION structure with
> AuthType equal to  TRUST_AUTH_TYPE_VERSION (3).

Great.  What is the kvno if the client does not provide one in that structure, 
when it initially calls CreateTrustedDomainEx?  (I think it is -1)

> A change will be made to the [MS-ADA2]document section 2.235 Attribute 
> msDS-KeyVersionNumber which will be similar to the following:
>
>   2.235 Attribute msDS-KeyVersionNumber For a given  user,
> computer or built-in account, this attribute specifies the Kerberos
> version number of the current key for that account. The Kerberos key
> version number for trusts is stored in the trusted domain object (TDO)
> whose object class is trustedDomain

Can i suggest a slight rewording:

For a trusted domain (objectClass trustedDomain), the Kerberos key version 
number is stored in the trusted domain object (TDO), embedded in the 
trustAuthIncoming and trustAuthOutgoing attributes.

Andrew Bartlett
--
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org
Samba Developer, Red Hat Inc.  http://redhat.com

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

[cifs-protocol] Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

[Adam Simpkins]

On Wed, Oct 08, 2008 at 07:55:52AM -0700, Bill Wesse wrote:
> My pleasure!
> 
> Here is copy of tentative text changes to the [MS-SPNG] document (these are 
> waiting for internal approval - I will advise you as soon as the text is 
> finalized):

Thanks.  The new text looks good.

-- 
Adam Simpkins
[EMAIL PROTECTED]
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[cifs-protocol] RE: MS-SAMR missing SID name use type ?

[Obaid Farooqi]

Hi Ronnie:
I need some clarification on your question. Please provide the answers to 
following questions:

1. Please specify the setup in which you see this in wireshark.
2. The exact scenario in which you see it.
3. Please send Wireshark or netmon trace where you see this emun member. Please 
also specify frame and byte where you see it.

Thanks
Obaid Farooqi

-Original Message-
From: ronnie sahlberg [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2008 11:35 AM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: MS-SAMR missing SID name use type ?

Hi,

I am a pfif subcontractor.

The IDL in MS-SAMR describes the types of sids as :

typedef enum _SID_NAME_USE {
SidTypeUser = 1,
SidTypeGroup,
SidTypeDomain,
SidTypeAlias,
SidTypeWellKnownGroup,
SidTypeDeletedAccount,
SidTypeInvalid,
SidTypeUnknown,
} SID_NAME_USE, *PSID_NAME_USE;


I believe there might be one additional value for this enum to
describe a sid for a machine/computer :

SidTypeComputer = 9   (or something similar)


This assumption is based on Wireshark and Samba4 code.


regards
ronnie sahlberg

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

[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

[Bill Wesse]

My pleasure!

Here is copy of tentative text changes to the [MS-SPNG] document (these are 
waiting for internal approval - I will advise you as soon as the text is 
finalized):

==
OID 1.2.840.113554.1.2.2 is ALWAYS included in the mechToken/responseToken.
--

Original text:

<5> Section 3.1.5.2:  Windows versions offer and accept two distinct OIDs as
identifiers for the Kerberos authentication mechanism. The SPNEGO
extensions consider both OIDs as equivalent and make no distinction
between them.

Windows 2000 incorrectly encoded the OID for the Kerberos protocol. Rather
than the OID { iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the
values at 16 bits. Therefore, the OID became { iso(1) member-body(2)
United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }. 48018 is
not a known member under that OID branch; this is an error.

Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
do not truncate the value, and they correctly offer and receive
1.2.840.113554.1.2.2. For compatibility reasons, the erroneous value
(1.2.840.48018.1.2.2) is still offered and accepted by systems that run
Windows 2000. The presence of this value can be used to determine that the
peer is a Windows 2000 implementation.

New text:

<5> Section 3.1.5.2:  Windows versions offer and accept two distinct OIDs as
identifiers for the Kerberos authentication mechanism. The SPNEGO
extensions consider both OIDs as equivalent and make no distinction
between them.

Windows 2000 incorrectly encoded the OID for the Kerberos protocol. Rather
than the OID { iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the
values at 16 bits. Therefore, the OID became { iso(1) member-body(2)
United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }. 48018 is
not a known member under that OID branch; this is an error. The singular
presence of this incorrect OID (1.2.840.48018.1.2.2) can be used to
determine that the peer is a Windows 2000 implementation.

Windows XP and later do not truncate the OID, and they correctly offer
and receive 1.2.840.113554.1.2.2. For compatibility reasons, on Windows XP
and later, the erroneous value (1.2.840.48018.1.2.2) is sent in addition
to the correct value (1.2.840.113554.1.2.2) Both values are considered
equivalent and Windows makes no distinction between the two.

The mechToken and responseToken always contain the standard OID
(1.2.840.113554.1.2.2) within the thisMech field, even when the
supportedMech chosen by SPNEGO is (1.2.840.48018.1.2.2). Windows Kerberos
servers do not accept the "truncated" OID in the thisMech field.

Regards,
Bill Wesse
MCSE / 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
We're Hiring 
http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted


-Original Message-
From: Adam Simpkins [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2008 10:08 PM
To: Bill Wesse
Cc: '[EMAIL PROTECTED]'
Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in 
GSS-API/SPNEGO

On Fri, Oct 03, 2008 at 07:18:05AM -0700, Bill Wesse wrote:
> Good morning again! Our documentation development team advises me the 
> following change will be implemented in a future posting of [MS-SMB]:
>
> [MS-SMB]: Server Message Block (SMB) Protocol Specification
> Section 3.2.4.2.3 User Authentication (Extended Security subtopic)
>
> Current Text:
>
> In either case, it initializes the GSS authentication protocol with the 
> MutualAuth and Delegate options, which are specified in [MS-KILE] section 
> 3.2.1.1.<173>
>
> Request to update with:
>
> In either case, it initializes the GSS authentication protocol with the 
> MutualAuth and Delegate options, which are specified in [MS-KILE] section 
> 3.2.1.1.<173> See also [MS-SPNG] section 3.2.5.2.

Okay.  Thanks for the update.

--
Adam Simpkins
[EMAIL PROTECTED]

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