[cifs-protocol] RE: Meaning of ACB_PWNOTREQ / UF_PASSWD_NOTREQD
Good morning Andrew. Thanks for your question. I have created the below case for you on this matter; one of my colleagues or I will take ownership of this and contact you shortly. SRX080905600018 [MS-ADTS] 2.2.15 ADS_UF_PASSWD_NOTREQD semantics 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 -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2008 11:13 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Meaning of ACB_PWNOTREQ / UF_PASSWD_NOTREQD In Samba4, we map the userAccountControl flag UF_PASSWD_NOTREQD to the SAMR flag ACB_PWNOTREQ, and we use this to indicate 'no password (or any password) required for this account'. That is, when this flag is set, and NULL passwords are permitted (as a global setting 'null passwords = yes' in the smb.conf), we allow any password to operate/log in to the marked account. However, I'm not sure if this is the meaning Microsoft assigns to this flag. Could you please clarify AD's behaviour in the situation where this flag is set on an user account? If this is not the correct way to handle 'no password required for logon', Is there another way to indicate this? Thanks, (I want to get this right, or else migrations from Windows domains might open a security hole) 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
[cifs-protocol] Status: raw NTLMSSP tokens in GSS-API/SPNEGO (SRX080803600053)
Good morning Adam. Documentation development advises me they are waiting for
feedback from the Security team on Windows Behaviors with regards to NTLM and
SPNEGO blobs.
Thanks for your patience.
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-05A82B88383Estart=1interval=10SortCol=DatePosted
-Original Message-
From: Bill Wesse
Sent: Thursday, September 04, 2008 9:24 AM
To: 'Adam Simpkins'
Subject: RE: [cifs-protocol] Re: Response (document change proposals): raw
NTLMSSP tokens in GSS-API/SPNEGO? SRX080803600053
Thanks for the heads up Adam - sorry I haven't responded sooner. Development
has not yet provided any response information.
I have alerted the assigned developers!
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-05A82B88383Estart=1interval=10SortCol=DatePosted
-Original Message-
From: Adam Simpkins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 2:51 PM
To: Bill Wesse
Subject: Re: [cifs-protocol] Re: Response (document change proposals): raw
NTLMSSP tokens in GSS-API/SPNEGO? SRX080803600053
Bill,
I haven't seen an update on this issue in a while. Any news?
--
Adam Simpkins
[EMAIL PROTECTED]
On Wed, Aug 20, 2008 at 05:14:48PM -0700, Adam Simpkins wrote:
Bill,
I've generated some new, cleaned up traces that can be included in the
documentation if you wish. The accompanying README.txt file describes
each of the individual traces.
Below I've listed how the trace files relate to the existing
discussion. I've also added a few additional comments about the
proposed changes:
On Thu, Aug 14, 2008 at 10:44:03PM -0700, Adam Simpkins wrote:
On Wed, Aug 13, 2008 at 09:59:37AM -0700, Bill Wesse wrote:
[MS-SPNG]: Simple and Protected Generic Security Service Application
Program
Interface Negotiation Mechanism (SPNEGO) Protocol Extensions
Change:
3.1.5.2 mechTypes Identification of Kerberos
5
To:
3.1.5.2 mechTypes Identification of Kerberos
Windows XP, Windows Server 2003, Windows Vista, and Windows Server offer
and
receive the mechType 1.2.840.113554.1.2.2 (Generic Security Service
Application Program Interface) when using Kerberos Version 5 technology),
{ iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2)
krb5(2) }.5
Inside the actual note 5 in Appendix A, it would be nice to also
mention that the inner mechToken/responseToken always contains the
standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when
the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2. Windows
servers do not accept the truncated OID in the thisMech field.
spnego_krb.cap shows the current Windows behavior of negotiating
1.2.840.48018.1.2.2. in the SPNEGO mechTypes list and supportedMech
field, but actually using 1.2.840.113554.1.2.2 inside the mechToken.
spnego_krb_ms_oid.cap shows that Windows servers fail the
authentication when 1.2.840.48018.1.2.2 is negotiated via SPNEGO and
this OID is also used as the thisMech field inside the mechToken.
krb_ms_oid.cap shows that Windows servers fail the authentication when
1.2.840.48018.1.2.2 is used as the thisMech field without SPNEGO.
And, for comparison, krb.cap shows that Windows servers accept the
standard KRB5 OID without SPNEGO.
[MS-SMB]: Server Message Block (SMB) Protocol Specification
3.2.4.2.3 User Authentication
snip
Thanks for the proposed changes. I have a few suggestions that might
improve upon this:
snip
With these changes, it could look perhaps something like:
Windows accepts raw NTLM NEGOTIATE messages that are not embedded in
[RFC2743] InitialContextTokens in the SecurityBlob of an
SMB_COM_SESSION_SETUP_ANDX request packet. This was introduced in
the NTLMv2 implementation of Windows NT 4 Service Pack 4. Windows
servers do not accept NTLM messages that are properly contained
inside a GSS InitialContextToken. The server responds with
STATUS_INVALID_PARAMETER.
Note: See the attached:
raw_ntlmssp.cap frame 7.
gss_ntlmssp.cap frame 7.
These references can remain unchanged. The new trace files have the
same names and the SESSION_SETUP_ANDX requests are in the same frames.
GSSAPI/SPNEGO support for Kerberos and NTLMSSP was introduced in
Windows 2000.
When SPNEGO is in use, [RFC4178]
RE: [cifs-protocol] Session keys are not always 16 bytes long
Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 10:36 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Stefan, I just found that the session key used to decrypt the password attributes in the DsGetNCChanges() is not truncated. Do you have network trace for this case ? See the attached capture and keytab. And I need to use gsskrb5_get_subkey() instead of gsskrb5_get_initiator_subkey(), when aes keys are used. Does this happen only when you use AES keys Yes, as for AES the acceptor subkey is different from the initiator one. Windows servers seem to just use the same subkey as acceptor subkey and the inititor subkey for rc4 and des keys. For me the remaining unsolved problem is smb signing with AES keys. If I disable mutual auth is works using the initiator subkey, but if mutual auth is used I'm getting a NT_STATUS_ACCESS_DENIED on the tree connect after the session setup. Both initiator and acceptor subkey doesn't work. And truncating the session key to 16 bytes also doesn't help. I attached 2 capture of it. SMB2 signing works fine with the 32byte acceptor subkey. Could it be a bug in windows? Or does smb signing works for you with AES keys and mutual auth? metze AESSinging.cap Description: AESSinging.cap ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Session keys are not always 16 bytes long
Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Session keys are not always 16 bytes long
Andrew Bartlett schrieb: On Fri, 2008-09-05 at 22:25 +0200, Stefan (metze) Metzmacher wrote: Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121).When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. I think I hit the same issue Samba/Samba last night (after I enabled mandatory smb signing in our server). Is your fix for this up somewhere? http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=v4-0-aes http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=b53e6387e30010509034835acf88b91b380ff44a metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
