Re: [cifs-protocol] [REG:113103010905266] Behaviour of UF_LOCKOUT compared with UF_PASSWORD_EXPIRED
On Tue, 2013-11-05 at 22:43 +, Edgar Olougouna wrote: > Andrew, > Just a quick ping to re-iterate the request for debugging traces. > I will be happy to investigate and clarify the observed behavior. If you can run the smbtorture command yourself, that would be great, but otherwise I'll try to get to it by the end of the week. I do apologise for being all hot and then cold on this, as you would understand I've been swamped with other things. For the moment I'm just masking the lockout flag back out in SAMR. You might be amused to know I'm currently writing slides about our recent fun with Backup for an internal company talk, to show what great things we can do and challenges we face when doing interoperability work. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:113103010905266] Behaviour of UF_LOCKOUT compared with UF_PASSWORD_EXPIRED
On Fri, 2013-11-01 at 02:08 +, Edgar Olougouna wrote: > Andrew, > Can you provide the network captures as well as TTT traces of lsass.exe? > What are the exact scenarios in your test cases where you observed > STATUS_ACCOUNT_LOCKED_OUT whereby the UF_LOCKOUT flag is not set but > UF_PASSWORD_EXPIRED is set? > Did the password expire first before you receive the error, or was the > account locked before the password expired? > What are the SAMR methods being called? > Did you test LDAP as well? The tests I have don't do LDAP for this, so it's just SAMR. I've not verified the semantics on PASSWORD_EXPIRED, but AUTOCLOCK does not show up even when SamLogon shows STATUS_ACCOUNT_LOCKED_OUT. All this is demonstrated by the smbtorture rpc.samr.passwords.lockout test. See source4/torture/rpc/samr.c line 4189 in git master. https://git.samba.org/?p=samba.git;a=blob;f=source4/torture/rpc/samr.c;h=a06529348e518fd9771bf2b0450fe86114b77cc8;hb=HEAD#l4189 I expect I'll have to wait until I'm back at work next week for a TTT trace. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Where is account lockout and password expiry described in the docs?
On Fri, 2013-10-25 at 11:53 +1300, Andrew Bartlett wrote: > On Fri, 2013-10-25 at 10:50 +1300, Andrew Bartlett wrote: > > On Fri, 2013-10-25 at 09:26 +1300, Andrew Bartlett wrote: > > > On Thu, 2013-10-24 at 20:16 +, Sebastian Canevari wrote: > > > > Hi Andrew, > > > > > > > > Do you need further assistance from my end? > > > > > > I do. I was waiting on: > > > > > > > > As soon as I have answers or questions I'll let you know. > > > > > > > > Thanks. Please also include the details for how this happens in > > > > Kerberos, not just for NTLM, as I strongly suspect the semantics have > > > > subtle differences, particularly in forwarding. > > > > > > There is still no clear document explaining how this is handled for > > > Kerberos, and nothing that clearly describes how a NetLogon SamLogon > > > translates into a badPwdCount update. > > > > > > I was waiting for those docs before proceeding, to avoid rework. > > > > I'm also wanting clarification on the UF_LOCKOUT flag in > > msDS-User-Account-Control-Computed and userAccountControl > > > > It appears that msDS-User-Account-Control-Computed should be referred to > > by SAMR, as the source of the lockout algorithm, but there no reference > > from MS-SAMR to this attribute. > > > > Indeed, it is unclear how UF_LOCKOUT and UF_PASSWORD_EXPIRED is to > > behave, as 3.1.1.6 (18) bans this bit, but in: > > > > 3.1.1.8.10 > > userAccountControl > > 1. If the UF_LOCKOUT bit (section 2.2.1.13) is set and the lockoutTime > > attribute is nonzero, the > > lockoutTime attribute MUST be updated to a value of zero. > > > > This implies that it can be set in userAccountControl. Also, the sense > > here seems backwards, surely clearing the bit sets lockoutTime to zero? > > > > Also it says: > > > > 2. The following bits, if set, MUST be unset before committing the > > transaction: UF_LOCKOUT and > > UF_PASSWORD_EXPIRED. > > > > This further confuses me as to if these are computed or stored flags > > (I'm assuming computed). > > > > This is the kind of level of detail I need in this area. > > Additionally, as I'll need to implement the > ms-DS-User-Account-Control-Computed attribute, how do I implement > 0x400 > UF_PARTIAL_SECRETS_ACCOUNT > 0x800 > UF_USE_AES_KEYS > > Because these are not included in MS-ADTS 3.1.1.4.5.17 > msDS-User-Account-Control-Computed Any update on these questions? Thanks, -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Behaviour of UF_LOCKOUT compared with UF_PASSWORD_EXPIRED
(BTW, I think my other thread got lost, so I'm starting back from scratch here) In 'MS-SAMR 3.1.5.14.11 User Field to Attribute Name Mapping' it says: *On read of UserAccountControl, the database attribute value MUST be: 1. Augmented with the UF_LOCKOUT bit if the lockoutTime attribute value on the target object is nonzero and if its value plus the Effective-LockoutDuration attribute value (section 3.1.1.5) is less than the current time. 2. Augmented with the UF_PASSWORD_EXPIRED if PasswordMustChange is less than the current time. However, testing (smbtorture's rpc.samr.passwords.lockout test shows that) only the UF_PASSWORD_EXPIRED bit shows via SAMR, the UF_LOCKOUT does not. That is, we get a STATUS_ACCOUNT_LOCKED_OUT without this flag being returned. In '3.1.5.14.6 Account Lockout State Maintenance' different rules appear to apply compared to MS-ADTS '3.1.1.4.5.17 msDS-User-Account-Control-Computed' The answers on these things matter to me, because I was trying to build the SAMR behaviour on the msDS-User-Account-Control-Computed behaviour. The MS-ADTS docs have regard for the account type, for example. Can you look into this, and assist me in understanding what rules are actually applied, and if these two calculations are deliberately out of sync? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Where is account lockout and password expiry described in the docs?
On Fri, 2013-10-25 at 10:50 +1300, Andrew Bartlett wrote: > On Fri, 2013-10-25 at 09:26 +1300, Andrew Bartlett wrote: > > On Thu, 2013-10-24 at 20:16 +, Sebastian Canevari wrote: > > > Hi Andrew, > > > > > > Do you need further assistance from my end? > > > > I do. I was waiting on: > > > > > > As soon as I have answers or questions I'll let you know. > > > > > > Thanks. Please also include the details for how this happens in > > > Kerberos, not just for NTLM, as I strongly suspect the semantics have > > > subtle differences, particularly in forwarding. > > > > There is still no clear document explaining how this is handled for > > Kerberos, and nothing that clearly describes how a NetLogon SamLogon > > translates into a badPwdCount update. > > > > I was waiting for those docs before proceeding, to avoid rework. > > I'm also wanting clarification on the UF_LOCKOUT flag in > msDS-User-Account-Control-Computed and userAccountControl > > It appears that msDS-User-Account-Control-Computed should be referred to > by SAMR, as the source of the lockout algorithm, but there no reference > from MS-SAMR to this attribute. > > Indeed, it is unclear how UF_LOCKOUT and UF_PASSWORD_EXPIRED is to > behave, as 3.1.1.6 (18) bans this bit, but in: > > 3.1.1.8.10 > userAccountControl > 1. If the UF_LOCKOUT bit (section 2.2.1.13) is set and the lockoutTime > attribute is nonzero, the > lockoutTime attribute MUST be updated to a value of zero. > > This implies that it can be set in userAccountControl. Also, the sense > here seems backwards, surely clearing the bit sets lockoutTime to zero? > > Also it says: > > 2. The following bits, if set, MUST be unset before committing the > transaction: UF_LOCKOUT and > UF_PASSWORD_EXPIRED. > > This further confuses me as to if these are computed or stored flags > (I'm assuming computed). > > This is the kind of level of detail I need in this area. Additionally, as I'll need to implement the ms-DS-User-Account-Control-Computed attribute, how do I implement 0x400 UF_PARTIAL_SECRETS_ACCOUNT 0x800 UF_USE_AES_KEYS Because these are not included in MS-ADTS 3.1.1.4.5.17 msDS-User-Account-Control-Computed Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Where is account lockout and password expiry described in the docs?
On Fri, 2013-10-25 at 09:26 +1300, Andrew Bartlett wrote: > On Thu, 2013-10-24 at 20:16 +, Sebastian Canevari wrote: > > Hi Andrew, > > > > Do you need further assistance from my end? > > I do. I was waiting on: > > > > As soon as I have answers or questions I'll let you know. > > > > Thanks. Please also include the details for how this happens in Kerberos, > > not just for NTLM, as I strongly suspect the semantics have subtle > > differences, particularly in forwarding. > > There is still no clear document explaining how this is handled for > Kerberos, and nothing that clearly describes how a NetLogon SamLogon > translates into a badPwdCount update. > > I was waiting for those docs before proceeding, to avoid rework. I'm also wanting clarification on the UF_LOCKOUT flag in msDS-User-Account-Control-Computed and userAccountControl It appears that msDS-User-Account-Control-Computed should be referred to by SAMR, as the source of the lockout algorithm, but there no reference from MS-SAMR to this attribute. Indeed, it is unclear how UF_LOCKOUT and UF_PASSWORD_EXPIRED is to behave, as 3.1.1.6 (18) bans this bit, but in: 3.1.1.8.10 userAccountControl 1. If the UF_LOCKOUT bit (section 2.2.1.13) is set and the lockoutTime attribute is nonzero, the lockoutTime attribute MUST be updated to a value of zero. This implies that it can be set in userAccountControl. Also, the sense here seems backwards, surely clearing the bit sets lockoutTime to zero? Also it says: 2. The following bits, if set, MUST be unset before committing the transaction: UF_LOCKOUT and UF_PASSWORD_EXPIRED. This further confuses me as to if these are computed or stored flags (I'm assuming computed). This is the kind of level of detail I need in this area. Please clarify, Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Where is account lockout and password expiry described in the docs?
On Thu, 2013-10-24 at 20:16 +, Sebastian Canevari wrote: > Hi Andrew, > > Do you need further assistance from my end? I do. I was waiting on: > > As soon as I have answers or questions I'll let you know. > > Thanks. Please also include the details for how this happens in Kerberos, > not just for NTLM, as I strongly suspect the semantics have subtle > differences, particularly in forwarding. There is still no clear document explaining how this is handled for Kerberos, and nothing that clearly describes how a NetLogon SamLogon translates into a badPwdCount update. I was waiting for those docs before proceeding, to avoid rework. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Where is account lockout and password expiry described in the docs?
On Thu, 2013-10-17 at 20:33 +, Sebastian Canevari wrote: > Yeah, sureusually click reply all... probably missed it today. > > So, does that article answer your questions? If so, I'll start checking with > the PG on how and what needs to be documented in ADTS. Not entirely, because I need clarification on how Kerberos is handled, and I need clarification on exactly what attributes to read/modify in what way. The SAMR reference seems to be the closest clue. Also, how should the previous password be handled in both cases? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Where is account lockout and password expiry described in the docs?
On Thu, 2013-10-17 at 15:51 +, Sebastian Canevari wrote: > Hi Andrew, > > I'll be helping you out with this request. > > As soon as I have answers or questions I'll let you know. Thanks. Please also include the details for how this happens in Kerberos, not just for NTLM, as I strongly suspect the semantics have subtle differences, particularly in forwarding. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Where is account lockout and password expiry described in the docs?
I've been looking for the formal documentation for account lockout and expiry handling. There are no references that I can find in The only reference in MS-ADTS is in 6.1.5.4 PDC Emulator FSMO Role, which gives the clue that we need to forward all bad passwords to the PDC. But that leaves a lot of questions, like what to do (what error to give) if the PDC is offline. The only reference in MS-SAMR is to actual enforcement is in .1.5.14.5 Account Lockout Enforcement and Reset, but this is for password change. There is also MS-SAMR 3.1.5.13.7.1 SamValidateAuthentication but nothing I could find indicates how this fits in to the broader picture. MS-NRPC refers to this as passthough authentication, and MS-NLMP does not describe expiry or lockout at all. Where can I find a clear description of how to implement account lockout (for bad passwords) and expiry? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] msDS-HasInstantiatedNCs
In MS-ADTS 6.1.1.2.2.1.2.1.1 nTDSDSA Object it says: msDS-HasInstantiatedNCs: Contains an Object(DN-Binary) value for each NC replica that is hosted by this DC. The DN field is the DN of the root object of the NC. The Binary field contains the value of the instanceType attribute on the root object of the NC. This is a binary encoding of attribute instanceType with little-endian byte ordering. Requirement: The DN fields of all the values of msDS-HasInstantiatedNCs must be equal to the set of DNs contained in the values of msDS-hasMasterNCs and hasPartialReplicaNCs. http://msdn.microsoft.com/en-us/library/cc223545%28v=prot.10%29.aspx Who is the Requirement enforced by? Is it a requirement that the client (the newly joining DC) set and maintain this, or that the existing DC being joined must maintain this? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Tue, 2012-06-12 at 15:56 +, Bryan Burgin wrote: > [+Jay Simmons] > > Hi Andrew. We made some progress on this issue. Below is the response from > Jay Simmons who researched this for you. Jay agreed to join this thread. > > "Thanks for your extreme patience on this issue.Your findings were > correct – Windows servers up through Windows Server 2003 will attempt to use > the well-known key “SystemLibraryDTC” to decrypt data, if no SMB session has > been established for the incoming client (which is usually the case when > invoking RPC calls over TCP).Windows servers after WS03 behave only > slightly better – for those OS versions, a “random” key will be used whose > contents depend on memory\stack contents at the time the call is made. > While the server-side behavior is not ideal, the client must still first be > authenticated and authorized for the operation (eg, password set) to be > allowed. Therefore the security vulnerability lies in the fact that the > client chose to expose sensitive data to a potential wire-sniffing attack, by > using an insecure means of making the call in the first place (this assumes > that RPC-level transport security was not leveraged to protect the data). > Note that we explicitly document in MS-SAMR (see section 2.1) which calls > must be made using RPC-over-SMB, at least in part for preventing exactly this > problem.No Windows client will ever invoke such a call (ie, one with > SMB-session-key encrypted parameters) without an SMB session. > > "This probably goes without saying, but please do not attempt to rely on this > behavior as it will likely be blocked at some point in the future. > > "Feedback welcomed, especially if you think we have misunderstood the > security implications of the issue." So, does this mean that the 'new' behaviour of NT_STATUS_NO_USER_SESSION_KEY is due to the stack being co-incidentally zero at this point, but that this might not always be the case? If windows ever creates a privileged, unsigned lsa connection over TCP, you could hijack it and use this to call querysecret to extract a secret value from the DC 'unencrypted'. I guess it's a long shot (lots of other avenues for attack), but it's one that might be possible. The annoying thing is that this issue *prevents* the use of RPC transport layer security for the most sensitive operations. I wanted to sign certain privileged connections setting up trusts (to prevent hijacking), but I can't as it means I have to use SystemLibraryDTC (and expose the secret) and some servers may reject it anyway. I also can't seal because some servers will reject it as NT_STATUS_NO_USER_SESSION_KEY. It would actually be better if SystemLibraryDTC was abolished, and replaced by the session key as used in DRSUAPI. This would then allow these calls to be made over secure RPC. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] encryption key for NetrLogonSamLogonEx
On Sat, 2012-02-11 at 15:40 -0800, Matthieu Patou wrote: > Hello Dochelp, > > A bug report concerning user's session key was reported in samba when > using level 3 validation for NetrLogonSamLogonEx. > > I did a bit of investigation and witnessed the corruption if we use > level 3 validation for NetrLogonSamLogonEx and if samba opens more than > 1 schannel connection with one DC and is not using the session key of > the latest connection for decrypting the user's session key (and other > encrypted fields) in the Validation 3 response. > > I checked that samba is using the same key for encrypting and decrypting > schannel and sensitive fields in the validation 3 response of the > NetrLogonSamLogonEx call. > > MS-NRPC seems to indicate that the session key should be the same and I > didn't find a trace in the documentation saying that only the latest > session key exchanged during a NetrAuthenticateX and what seems even > more puzzeling is that using the "old" session key for schannel > encryption and decryption works. > > Can you explain us the problem ? Matthieu, The issue is in part that RC4 encryption is not checksumed, and so the stream cipher has no way to tell if the encryption was in fact valid. Therefore, you can decrypt a returned session key with the wrong key and have no errors. The reason for my original patch in https://bugzilla.samba.org/show_bug.cgi?id=8599 is that only by validating the netlogon authentication chain can we have any confidence that we share the same session key as the remote server at this exact moment. Of course, when we can choose a level without netlogon authentication and without an encrypted session key, this is even better. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Mon, 2012-02-13 at 06:21 +, Bryan Burgin wrote: > Andrew, > > I'm touching base to see if you can provide the exact smbtorture steps to > reproduce your issue. bin/smbtorture ncacn_np:win2003r2-2[seal] rpc.lsa.secrets -Uadministrator%penguin win2003r2-2 is naturally a win2003r2 server, currently not a DC. I note with interest that this test fails with NO_USER_SESSION_KEY in win2k8r2, so I would like to know when this was changed and any important details, so we on the Samba Team can assess removing SystemLibraryDTC eventually. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Confirm kerberos key selection rules for PAC KDC signature
On Mon, 2012-01-30 at 20:26 +, Edgar Olougouna wrote: > Andrew, > > This happens in a typical scenario similar to the following. > > The DC is running Windows Server 2008 at domain functional level Windows > Server 2003. > The Kerberos client and server present following etypes to the DC: > EType: aes256-cts-hmac-sha1-96 (18) > EType: aes128-cts-hmac-sha1-96 (17) > EType: rc4-hmac (23) > > The client is issued a ticket with an encryption type aes256-cts-hmac-sha1-96 > (18). > The PAC in the in the service ticket has a SignatureType of > KERB_CHECKSUM_HMAC_MD5 (based of the logic described in my previous email, > condition 1) is met but condition 2) is not met). I'm clearly missing something here: How does the KDC issue a service ticket with type AES and not meet the requirements for an AES checksum on the PAC? Also, which key is the signature calculated with in this case? Also, can you explain how this describes the behaviour when the server only supports DES? We find that the SignatureType is of type KERB_CHECKSUM_HMAC_MD5 but they DES key (with which the ticket was encrypted) is in fact used for the HMAC calculation. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Mon, 2012-01-30 at 22:05 +, Bryan Burgin wrote: > Andrew, > > I'm working with Neil and others here. Can you tell us how to repro this > issue in-house? Wasn't that what we started this thread with? https://lists.samba.org/archive/cifs-protocol/2011-November/002213.html -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Confirm kerberos key selection rules for PAC KDC signature
On Fri, 2012-01-27 at 18:46 +, Edgar Olougouna wrote: > Andrew, > > After another look at the source code, I would try to describe how a > Windows-based KDC decides on the signature type of the PAC server signature. > Based on this, and the confirmation of the product team, it appears that the > current MS-KILE is correct. > > While there are several possible encryption types for the server key, there > are only three possible values for the signatureType in the PAC server > signature, as implemented in Windows Server 2008 R2 and documented in MS-KILE. > > Let’s assume the server key is of key type X. The key type is already known > before the PAC is signed; it is the strongest common type that can be used by > the application server and the KDC. When computing the PAC, Windows KDC > passes the server key as an input to the following logic. > > By default, the SignatureType KERB_CHECKSUM_HMAC_MD5 is used to compute the > PAC server signature, unless: > 1.the server key type X is one the newer encryption types i.e. AES256 or > AES128, > 2.AND > 2.1 the functional level of the domain NC is Windows Server 2008 or 2008 > R2, > 2.2 OR the registry setting disables the bit of HMAC-RC4 in the > SupportedEncryptionTypes (registry entry on the DC at the following > location (see KB977321): HKLM\Software\Microsoft\Windows > \CurrentVersion\Policies\System\Kerberos\parameters\) > > If the conditions 1) and 2) are met, the SignatureType will be > HMAC_SHA1_96_AES256 or HMAC_SHA1_96_AES128, depending on whether X is > AES256 or AES128. > > In a Windows-based domain, the strongest cryptography that the > “domain” supports depends on Windows Server SKUs of the domain > controllers (what cryptosystems are available) as well as the domain > functional level and configuration (what cryptosystems are supported). > > On Windows Server 2000 and 2003 based KDCs, the signatureType is > KERB_CHECKSUM_HMAC_MD5. > > When the server needs to validate the PAC signature, it uses the > SignatureType to determine the corresponding cryptographic system > used to calculate the checksum. The server however will use the long > term key that it shares with the KDC; that is the key of type X. > > For example, in real world, you may have a server key of key type > aes256-cts-hmac-sha1-96 (18), but a PAC server signature with > SignatureType KERB_CHECKSUM_HMAC_MD5, based what I have described > previously. How exactly would this happen? How would the domain create a ticket with X of AES256 or AES128 if that cryptosystem is not enabled and therefore available for creating a PAC signature of the same thing? At least we have now settled that the SignatureType is not the highest cryptography that the "domain" supports, because the key type of X is considered in the algorithm. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Fri, 2012-01-27 at 17:20 +, Bryan Burgin wrote: > > > Andrew, > > > > We completed our investigation to this issue and propose the following > changes to [MS-DTYP], [MS-LSAD], [MS-SAMR] and [MS-WKST]. The text > below contains yellow highlighting to identify changed text. If the > highlighting causes a problem for you, please let me know. The proposed text keeps referring to an Anonymous session key, but this happens when the user is authenticated at the DCE/RPC pipe level. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Confirm kerberos key selection rules for PAC KDC signature
On Thu, 2012-01-26 at 19:10 +, Edgar Olougouna wrote: > Andrew, > > Regarding your observation on “MS-KILE 3.3.5.3.2.3 Server Signature”: > > We confirm that the document is correct. > The statement: > “the strongest cryptography that the domain supports” > is related to the SignatureType of the checksum instead of the server account > key. > > Based on this investigation, I have suggested to the product team to revise > the text as follows. > > MS-KILE 3.3.5.3.2.3 Server Signature: > > The KDC creates a keyed hash ([RFC4757]) of the entire PAC message with the > Signature fields of both PAC_SIGNATURE_DATA structures set to zero using: > • the server account key, > • the strongest cryptography that the domain supports<30>, (see > SignatureType). > The KDC populates the returned PAC_SIGNATURE_DATA structure ([MS-PAC] section > 2.8) fields as follows: > • The SignatureType SHOULD be the value ([MS-PAC] section 2.8) > corresponding to the cryptographic system used to calculate the checksum. > • The Signature field SHOULD be the keyed hash ([RFC4757]) of the > entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA > structures set to zero. Edgar, I'm sorry, but this all makes very little sense when applied to the real world. Firstly, what is this SHOULD business? Both of these statements are MUSTS: If the SignatureType is not the 'value of the cryptographic system used to calculate the checksum', how could it ever be validated? If the the has is not over 'entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero' how could it ever work? Secondly, how does this statement match up with a server that does not understand AES? If this statement were true, then a pre-AES server (Win2000 for arguments sake) could never verify a PAC, as in an AES-capable domain (Win2008R2), it would be signed using a signature type simply never invented at the time the software was released. Finally, this still does not explain this behaviour: > The semantics where > the hmac-md5 keyed checksum is used to verify DES keys (rather than the DES > checksum) should also be noted here. > > Our source code comment is: >/* If the checksum is HMAC-MD5, the checksum type is not tied to > * the key type, instead the HMAC-MD5 checksum is applied blindly > * on whatever key is used for this connection, avoiding issues > * with unkeyed checksums on des-cbc-md5 and des-cbc-crc. See > * > http://comments.gmane.org/gmane.comp.encryption.kerberos.devel/8743 > * for the same issue in MIT, and > * > http://blogs.msdn.com/b/openspecification/archive/2010/01/01/verifying-the-server-signature-in-kerberos-privilege-account-certificate.aspx > * for Microsoft's explaination */ > > While neither of the links directly addresses the DES issue, it has come > up for us in the real world. Given that a server may or may not > support AES based on it's supported encryption types, the statement that it > is the 'strongest cryptography that the domain supports' seems unlikey. Please have another look over this. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Confirm kerberos key selection rules for PAC KDC signature
MS-KILE 3.3.5.3.2.3 Server Signature suggests: The KDC creates a keyed hash ([RFC4757]) of the entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero using the server account key with the strongest cryptography that the domain supports<30> and populates the returned PAC_SIGNATURE_DATA structure ([MS-PAC] section 2.8) fields as follows: Would it not be more correct to say that the KDC creates a keyed hash with the key with which the ticket is encrypted to the target server? Samba has always used that key to verify the PAC. The semantics where the hmac-md5 keyed checksum is used to verify DES keys (rather than the DES checksum) should also be noted here. Our source code comment is: /* If the checksum is HMAC-MD5, the checksum type is not tied to * the key type, instead the HMAC-MD5 checksum is applied blindly * on whatever key is used for this connection, avoiding issues * with unkeyed checksums on des-cbc-md5 and des-cbc-crc. See * http://comments.gmane.org/gmane.comp.encryption.kerberos.devel/8743 * for the same issue in MIT, and * http://blogs.msdn.com/b/openspecification/archive/2010/01/01/verifying-the-server-signature-in-kerberos-privilege-account-certificate.aspx * for Microsoft's explaination */ While neither of the links directly addresses the DES issue, it has come up for us in the real world. Given that a server may or may not support AES based on it's supported encryption types, the statement that it is the 'strongest cryptography that the domain supports' seems unlikey. Anyway, the reason I ask is to verify the behaviour for the KDC checksum: 3.3.5.3.2.4 KDC Signatures The KDC creates a keyed hash ([RFC4757]) of the Server Signature field using the strongest "krbtgt" account key and populates the returned PAC_SIGNATURE_DATA structure field ([MS-PAC] section 2.8) as follows: The SignatureType SHOULD be the value ([MS-PAC] section 2.8) corresponding to the cryptographic system used to calculate the checksum. The Signature field SHOULD be the keyed hash ([RFC4757]) of the Server Signature field in the PAC message. Can you confirm this is correct? I am working on a customer issue regarding the selection of the correct encryption type here, in an all-Samba situation, but in fixing that, I do not wish to break interoperability with Microsoft, so clarity here would be most welcome. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Puzzled: Heimdal upgrade breaks Win2k8 dcpromo
Dochelp,
The issue I have is a very odd one. I'm trying to import a new snapshot
of Heimdal into Samba4. I do this every now and then, and it is
naturally good practice to ensure it continues to work with Windows.
It appears to work with Windows 7, but when I dcpromo from a Win2008R2
machine to a Samba4 domain, I get 'Logon Failure: the username or
password is incorrect'.
The error occurs in the reply to an AS-REQ, with error
KRB5KDC_ERR_PREAUTH_REQUIRED (25)
The big difference in this error packet between old and new versions is
the inclusion of FAST, but then I patched that back out and it still
fails.
I have prepared git branches in git://git.samba.org/abartlet/samba.git
import-lorikeet-1 is the old code, this works (good)
import-lorikeet-2 is the new code, and fails (bad)
import-lorikeet-3 is includes a patch that results in an identical
(timestamp aside) KRB-ERROR packet to import-lorikeet-1. This also
fails. (not-match)
I would suspect that the error is elsewhere, but I cannot find any other
interesting packets, and in the working case (packet 14), the kerberos
exchange continues to a clock skew (packet 23), and then a successful
AS-REP (32).
My question is: How do I find out why the Windows 2008R2 client running
dcpromo is convinced that the error is 'username or password is
incorrect'? No password is ever presented, and the same underlying
Samba DB is used, so I know this is not the problem...
I've CC'ed Love, the Heimdal maintainer in case he has any clues.
I've included the good, bad and 'not-match' (my attempt to revert only
the change in the KRB-ERROR AS-REP packet) packets in various formats as
attachments. Also I include the pcap trace.
Andrew Bartlett
--
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
bad-as-rep
Description: Binary data
bad-as-rep.dump
Description: Binary data
bad-error.dump
Description: Binary data
0 123: SEQUENCE {
29: SEQUENCE {
43: [1] {
61: INTEGER 16
: }
92: [2] {
110: OCTET STRING
: Error: Object has zero length.
: }
: }
139: SEQUENCE {
153: [1] {
171: INTEGER 15
: }
202: [2] {
220: OCTET STRING
: Error: Object has zero length.
: }
: }
249: SEQUENCE {
263: [1] {
281: INTEGER 2
: }
312: [2] {
330: OCTET STRING
: Error: Object has zero length.
: }
: }
35 10: SEQUENCE {
374: [1] {
392: INTEGER 138
: }
432: [2] {
450: OCTET STRING
: Error: Object has zero length.
: }
: }
47 10: SEQUENCE {
494: [1] {
512: INTEGER 136
: }
552: [2] {
570: OCTET STRING
: Error: Object has zero length.
: }
: }
59 64: SEQUENCE {
613: [1] {
631: INTEGER 19
: }
66 57: [2] {
68 55: OCTET STRING, encapsulates {
70 53: SEQUENCE {
72 51: SEQUENCE {
743: [0] {
761: INTEGER 18
: }
79 36: [1] {
81 34: GeneralString 'S4.HOWTO.ABARTLET.NETAdministrator'
: }
1176: [2] {
1194: OCTET STRING 00 00 10 00
: }
: }
: }
: }
: }
: }
: }
good-as-rep
Description: Binary data
good-as-rep.dump
Description: Binary data
: 0141 7e82 013d 3082 0139 a003 0201 ...A~..=0..9
0010: 05a1 0302 011e a411 180f 3230 3131 3132 ..201112
0020: 3134 3032 3537 3338 5aa5 0502 030b f677 14025738Z..w
0030: a603 0201 19a7 171b 1573 342e 686f 7774 .s4.howt
0040: 6f2e 6162 6172 746c 6574 2e6e 6574 a81a o.abartlet.net..
0050: 3018 a003 0201 01a1 1130 0f1b 0d61 646d 00...adm
0060: 696e 6973 7472 6174 6f72 a917 1b15 7334 inistrators4
0070: 2e68 6f77 746f 2e61 6261 7274 6c65 742e .howto.abartlet.
0080: 6e65 74aa 2a30 28a0 0302 0102 a121 301f net.*0(..!0.
0090: 1b06 6b72 6274 6774 1b15 7334 2e68 6f77 ..krbtgt..s4.how
00a0: 746f 2e61 6261 7274 6c65 742e 6e65 74ab to.abartlet.net.
00b0: 2b1b 294e 6565 6420 746f 2075 7365 2050 +.)Need to use P
00c0: 412d 454e 432d 5449 4d45 5354 414d 502f A-ENC-TIMESTAMP/
00d0: 5041 2d50 4b2d 4153 2d52 4551 ac67 0465 PA-PK-AS-REQ.g.e
00e0: 3063 3009 a103 0201 02a2 0204 0030 09a1 0c0..0..
00f0: 0302 0
Re: [cifs-protocol] [REG:111101553031054] RE: SystemLibraryDTC
On Tue, 2011-11-15 at 03:56 +, Hongwei Sun wrote: > Andrew, > > After reviewing code, we confirmed that this fixed session key are > used by some SAMR/LSAD RPC functions. We are working on updating all > the related documents. When they are available , I will let you know. Thanks! Now would also be a good time to work out a way to remove them :-). I would be very happy to work with your developers on a secure way we can indicate to a server that these keys should not be used, or that they should only be available over encrypted transports. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] RE: SystemLibraryDTC
On Fri, 2011-10-21 at 22:58 +, Hongwei Sun wrote: > Andrew, > > I am working with multiple product teams and we want to understand the > scenario better. I searched and found some logs from Samba site regarding > this issue as below: > > 06/01/06 12:37:21 abartlet_: Can you tell me the story about > SystemLibraryDTC? > 06/01/06 12:37:32 What is that exactly, when is that used? > 06/01/06 12:38:20 so, you know how administrative password sets > are encrypted from the client to the SAMR server? > 06/01/06 12:38:40 Yes. This is what Samba3 with an ntlmssp authenticated > bind stumbles over right now :-) > 06/01/06 12:38:48 well, because windows doesn't always use the > bulk encryption, the values are indivdually encrypted > 06/01/06 12:39:39 anyway, when we are bulk encrypted, or when we > are on TCP/IP, the key is SystemLibraryDTC > 06/01/06 12:39:59 Otherwise it's taken from the session setup? > 06/01/06 12:40:02 yep > 06/01/06 12:40:08 I'm trying to design a torture test that joins samba3 > and then does an schannel bind / samlogon and is runnable in the build farm... > 06/01/06 12:40:22 ahh, fun :-) > 06/01/06 12:40:37 So I chose a null smb connection and did a ntlmssp > bind as root. This is not able to set the user password. > 06/01/06 12:41:02 So when the bind negotiates seal we can set the > sessionkey to SystemLibraryDTC? > 06/01/06 12:41:05 yep > >Is this the correct description of the scenario ?Which SAMR > functions are involved here ?The conversation above implies > SamrChangePasswordUser/SamrOemChangePasswordUser2/SamrUnicodeChangePasswordUser2. > Is this right ? Yes, those functions are known to use this. Also the secrets calls on LSA (that's where we did the DES brute force, as it was a weaker encryption). See the rpc.secrets smbtorture test, when used with either ncacn_ip_tcp, ncacn_ip_np:server[sign] or ncacn_ip_np:server[seal]. For security, I would really like to work with Microsoft to see this fixed key removed, or made unavailable over any unencrypted transport some day. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] RE: SystemLibraryDTC
On Tue, 2011-10-18 at 19:57 +, Hongwei Sun wrote: > Andrew, > > I confirmed that the fixed session key "SystemLibraryDTC" is only > used by NTLM when the client and server are both on the same machine. > This type of loopback behavior doesn't affect interoperability and > thus is not covered by the protocol documentation. Please let me > know if you have more questions. This is not the case, or else we would not know about it, and would not need to deal with it for interoperability. Sadly you will need to dig deeper, as we discovered it the hard way (ie, needing to discover the magic fixed key by DES brute force), I can assure you it is used outside the server. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SystemLibraryDTC
Tridge and I out of curiosity looked up SystemLibraryDTC in the documentation, and couldn't find it. For those unaware of the history here, this is the fixed-value key used for encryption of passwords and other sensitive data over RPC pipes, when RPC-level authentication is used (ie, not inherited named pipe authentication). (The exception is DRSUAPI, which uses the real session key from the authentication context). Did our grep simply miss it, or did this never get documented? Recent work we did with calls needing this key (CreateTrustedDomainEx2) returning NT_STATUS_NO_SESSION_KEY, which suggests a possible windows behaviour change. I hope what I've written above gives enough detail to start looking into the problem. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 111083054067588] RE: Handling of passwords in LSA CreateTrustedDomainInfoEx2
On Wed, 2011-08-31 at 20:37 +, Hongwei Sun wrote: > Hi, Andrew, > > >Is the element stored 'as sent', or is it processed to add a version field? > > ANS:After code review, I confirmed that AuthenticationInformation is > decrypted into LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION (as specified in > 2.2.7.11), then is just copied straightforwardly into the TrustAuthIncoming > and TrustAuthOutgoing properties as specified 7.1.6.9.1 MS-ADTS. As you > know, the LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION is a structure and > TrustAuthIncoming and TrustAuthOutgoing properties are String(Octet), there > are certainly some calculation for offsets required as per the layout of the > properties, but there is no new field added when marshaling the structure to > the octet string saved in the properties. > > >Can the client send the previousAuthentication details, or is that > >maintained by the server? > > ANS: Yes, the client can send the previousAuthentication for both incoming > and outgoing AuthticationInformation through LsarCreateTrustedDomainEx2. If > it is send, the server will save it to the previousAuthenticationInformation > part of the property (7.1.6.9.1 MS-ADTS). If it is not send, the > previousAuthenticationInformation in the property will be the same as current > AuthenticationInformation since this is a new TDO created and there is no > previous information available. > > > >In LsarSetInformationTrustedDomain > >http://msdn.microsoft.com/en-us/library/cc234385%28v=PROT.13%29.aspx > >Does the client or the server maintain the previous password and version > >information in the blob in the "trustAuthIncoming"? > > ANS: The server will be responsible for updating the previous > authentication information in "TrustAuthIncoming" property. When server > receives this call, it will first query the information about the trusted > domain object (TDO) identified by the TrustedDomainHandle passed into > LsarSetInformationTrustedDomain. Then the server will save the returned > trusted domain information as previousAuthentication and the passed > authenticationInformation as new AuthticationInformation in TrustAuthIncoming > property. > > Please let me know if you have more questions. Thanks, that resolves this for now. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Errors when doing a DsAddEntry
On Wed, 2011-08-31 at 15:22 +, Hongwei Sun wrote: > Andrew, > >Can you give the information about your configuration ? Are you joining > Samba DC to a Windows DC ? We were attempting to create a subdomain using Samba4 as the new domain. > If so, what is the version of Windows DC ?Are you referring to the > section "4.1.1.3 Server Behavior of the IDL_DRSAddEntry Method" of MS-DRSR > for the "impossible" error case ? The only occurrences of these error constants in the docs were for calls other than AddEntry. >Is it possible for you to capture a TTT trace for Windows server when > error is returned so I can analyze the behavior ? If so , I can create a > FTP workspace for you to upload the trace captured ? Tridge may be able to help with that (it was on his systems). We are also continuing to work on the issues, harmonising our behaviour with the example Windows packet trace I took. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Errors when doing a DsAddEntry
We have been looking at DRSUAPI/DsAddEntry, and have a few questions. We are trying to implement subdomain support in Samba4 before the plugfest. We have been able to generate error cases that do not seem to be 'possible' in the docs. Can you please clarify exactly what errors this function should be able to return, and document how to avoid these: in join-s1.txt we have an error that is only listed in the docs when removing a DC from the domain. extended_err : WERR_DS_ROLE_NOT_VERIFIED This is currently blocking us. Our only theory is that we must perform a replication cycle before we do this call. in join-s1-2.txt we have another error, that we worked around by creating the partitions object before creating the server object. However, as we need to match the server-side behaviour, we need to know the undocumented circumstances that cause this error. extended_err : WERR_DS_NO_CROSSREF_FOR_NC Finally, is there any documentation of the high-level procedure for creating a subdomain? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org lpcfg_load: refreshing parameters from /home/tridge/samba/git/prefix.s2/etc/smb.conf drsuapi_DsBind: struct drsuapi_DsBind in: struct drsuapi_DsBind bind_guid: * bind_guid: e24d201a-4fd6-11d1-a3da-f875ae0d bind_info: * bind_info: struct drsuapi_DsBindInfoCtr length : 0x001c (28) info : union drsuapi_DsBindInfo(case 28) info28: struct drsuapi_DsBindInfo28 supported_extensions : 0x0fefff7f (267386751) 1: DRSUAPI_SUPPORTED_EXTENSION_BASE 1: DRSUAPI_SUPPORTED_EXTENSION_ASYNC_REPLICATION 1: DRSUAPI_SUPPORTED_EXTENSION_REMOVEAPI 1: DRSUAPI_SUPPORTED_EXTENSION_MOVEREQ_V2 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHG_COMPRESS 1: DRSUAPI_SUPPORTED_EXTENSION_DCINFO_V1 1: DRSUAPI_SUPPORTED_EXTENSION_RESTORE_USN_OPTIMIZATION 0: DRSUAPI_SUPPORTED_EXTENSION_ADDENTRY 1: DRSUAPI_SUPPORTED_EXTENSION_KCC_EXECUTE 1: DRSUAPI_SUPPORTED_EXTENSION_ADDENTRY_V2 1: DRSUAPI_SUPPORTED_EXTENSION_LINKED_VALUE_REPLICATION 1: DRSUAPI_SUPPORTED_EXTENSION_DCINFO_V2 1: DRSUAPI_SUPPORTED_EXTENSION_INSTANCE_TYPE_NOT_REQ_ON_MOD 1: DRSUAPI_SUPPORTED_EXTENSION_CRYPTO_BIND 1: DRSUAPI_SUPPORTED_EXTENSION_GET_REPL_INFO 1: DRSUAPI_SUPPORTED_EXTENSION_STRONG_ENCRYPTION 1: DRSUAPI_SUPPORTED_EXTENSION_DCINFO_V01 1: DRSUAPI_SUPPORTED_EXTENSION_TRANSITIVE_MEMBERSHIP 1: DRSUAPI_SUPPORTED_EXTENSION_ADD_SID_HISTORY 1: DRSUAPI_SUPPORTED_EXTENSION_POST_BETA3 0: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V5 1: DRSUAPI_SUPPORTED_EXTENSION_GET_MEMBERSHIPS2 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V6 1: DRSUAPI_SUPPORTED_EXTENSION_NONDOMAIN_NCS 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V8 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREPLY_V5 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREPLY_V6 1: DRSUAPI_SUPPORTED_EXTENSION_ADDENTRYREPLY_V3 1: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREPLY_V7 1: DRSUAPI_SUPPORTED_EXTENSION_VERIFY_OBJECT 0: DRSUAPI_SUPPORTED_EXTENSION_XPRESS_COMPRESS 0: DRSUAPI_SUPPORTED_EXTENSION_GETCHGREQ_V10 0: DRSUAPI_SUPPORTED_EXTENSION_RESERVED_PART2 0: DRSUAPI_SUPPORTED_EXTENSION_RESERVED_PART3 site_guid: ---- pid : 0x (0) repl_epoch : 0x (0) drsuapi_DsBind: struct drsuapi_DsBind out: struct drsuapi_DsBind bind_info: * bind_info: struct drsuapi_DsBindInfoCtr length : 0x0030 (48) info
[cifs-protocol] Handling of passwords in LSA CreateTrustedDomainInfoEx2
In CreateTrustedDomainInfoEx2 http://msdn.microsoft.com/en-us/library/cc234380%28v=PROT.13%29.aspx I'm wondering if I could get an expansion on: AuthenticationInformation: A structure containing authentication information for the trusted domain. The server first MUST decrypt this data structure using an algorithm (as specified in section 5.1.1) with the key being the session key negotiated by the transport. The server then MUST unmarshal the data inside this structure and then store it into a structure whose format is specified in section 2.2.7.11. This structure MUST then be stored on Trust Incoming and Outgoing Password properties. In particular, what elements become assigned to "trustAuthIncoming" and "trustAuthOutgoing" Is the element stored 'as sent', or is it processed to add a version field? Can the client send the previousAuthentication details, or is that maintained by the server? In LsarSetInformationTrustedDomain http://msdn.microsoft.com/en-us/library/cc234385%28v=PROT.13%29.aspx Does the client or the server maintain the previous password and version information in the blob in the "trustAuthIncoming"? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:RE: [REG:111062276428612] RE: userParameters attribute
On Mon, 2011-08-22 at 22:27 +0200, Matthieu Patou wrote: > Hi Hongwei, > > Hum it looks ok, but what about the replication between 2 DCs ? the > value should be concidered as a blob of bytes and not as a string no ? Matthieu, This would not be an issue for Microsoft, as they replicate and store in 'UTF16'. We need to override our handling of this attribute, and only return it as a 'string' when dealing with an LDAP client. That way, our internal users can deal with it as a byte buffer, just like all other binary attributes. Andrew Bartlett -- Andrew Bartlett ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 111052361876778] RE: userParameters attribute
On Mon, 2011-06-20 at 20:14 +, Hongwei Sun wrote: > Metze/Andrew, > >We updated the description of userParameters in MS-ADA3 and other related > documents to clarify that it is not saved as utf16 or utf8 Unicode strings as > below. They will appear in the next release of the open protocol documents. The key point that seems to be brushed over here is: how is this 'not UTF8' string in LDAP translated into and from the representation sent over SAMR (which appears to be UTF16)? For example, please explain how the values seen in this bug get translated between each other. At a first glance, the translation does indeed appear to be that between UTF16 and UTF8, so if they are not UTF16 and UTF8 strings, what are they, and what defines the translation? https://bugzilla.samba.org/show_bug.cgi?id=8077 Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 111052361876778] RE: userParameters attribute
On Fri, 2011-05-27 at 22:40 +, Hongwei Sun wrote: > Metze, > >The UserParameters attribute was documented in 2.345 MS-ADA3. It is > defined as a Unicode string as below: > > " This attribute specifies parameters of the user. Points to a Unicode > string that is set aside for use by > applications. This string can be a null string, or it can have any number of > characters before the > terminating null character. Terminal servers use this attribute to store > session configuration data for > the user. For more information, see [MS-TSTS]." > > As per MD-GLOS , throughout the protocol document, unless otherwise > specified , an Unicode string follows the UTF- > 16LE encoding scheme with no Byte Order Mark (BOM). so it is not documented > as UTF8 Unicode string. > >But I am wondering if it matters what kind of Unicode encoding (utf8 vs > utf16) is used.The structure layout of this attribute is documented in > 2.3.1 MS-TSTS. It is just a BLOB interpreted by the Terminal Service , not a > null terminated Unicode string.We may be not correct to define the > attribute as a Unicode string (attributeSyntax: 2.5.5.12 ) in 2.345 MS-ADA3. > I will file a request to check with the product team. I thought it wasn't NULL terminated in the traditional sense, as the Terminal Services stuff has embedded NULLs, and was after a NULL that allowed it to be stuffed there in the first place. The story I recall is that when Terminal services was first developed outside Microsoft, that the dialback string for RAS was the only parameter in the SAM that could be safely extended, and this was done after the initial terminating NULL (of the RAS dialback string). We have had some real trouble dealing with this over time, with Samba3 domains hosting terminal services, and that's why we want to get this right, once and for all for Samba4. In particular, we are keen to ensure we know exactly the right transformations required between the LDAP and RPC representations. Even if it is a duplicate, it is a special enough case to warrant a clear, specific explanation or clarification. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] [REG:110011477385004] RE: userParameters attribute
On Mon, 2010-06-21 at 22:54 +, Hongwei Sun wrote: > Andrew, > > Sorry about the delay to give you a confirmation. We have been spending > time to review the usage of UserParameters in other Windows components based > on the information you provided. We found that this attribute is indeed > still used by at least one other Microsoft product, such as RAS Server. The > related product team is working on this to find how to document it. During > my vacation, I will ask one of my team member (Obaid) to monitor the progress > and send you the update when it is available. Out of pure curiosity, did this ever turn into documentation? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111020250601482] RE: Please provide windows behaviour notes on MS-KILE's reference to Referrals-11
On Mon, 2011-04-18 at 16:57 +, Obaid Farooqi wrote: > Hi Andrew: > Please let me know if the following document changes answer your question. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like to > provide feedback on your case you may contact my manager at > allis...@microsoft.com Honestly, your original step-by-step description and example answered my question, and should be included in the docs, as it was the most useful way to explain this. I have no idea if I could work it out from the amended document. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111020250601482] Please provide windows behaviour notes on MS-KILE's reference to Referrals-11
On Thu, 2011-02-10 at 22:20 +, Obaid Farooqi wrote: > Hi Andrew: > I am in the process of filing a document bug for this issue but in the > meantime here is the reason why Windows Server 2003 behaves this way and how > Windows KDC deals with it. > > Windows Server 2003 has a test in the code that test if there is a referral > loop. Here is what happens: > > My domain name is S4DOM.NET and the NETBIOS name is S4DOM. In this scenario, > due to referral, there are two TGT’s. One returned in AS Response will be > referred to as TGT1 and the one returned in the TGS response will be referred > to as TGT2. > For this discussion, I’ll use Sname as servicename/hostname where host name > is either or . > > Here is what happens: > 1.WS2k3 client sends AS Request with Realm = s4dom and Sname = > krbtgt/s4dom > 2.In AS Response, Samba KDC sends TGT1. TGT1 contains Realm = s4dom.net > and Sname = krbtgt/s4dom > 3.WS2k3 send a TGS request with Realm = s4dom and Sname = krbtgt/s4dom.net > 4.Samba KDC sends the TGS response that contains TGT2. In TGT2 , Realm is > s4dom.net and sname is krbtgt/s4dom.net > > > Windows 2003 checks for referral loop as follows: > > > (Realm in TGT1 == hostname in TGT2) AND !(hostname in TGT1 == hostname in > TGT2) Just so I'm clear, hostname in your examples here is the realm component of a krbtgt principal? ie krbtgt/@? > If the expression evaluates to TRUE, a loop is detected and the error you are > observing is shown to the user. > > Clients of Windows Vista and onwards do not make this check. > > Windows KDC deals with this situation by sending both Realm in TGT1 and > hostname in TGT1 the same (s4dom.net in this case). > This causes client to send TGS Request with Realm and hostname as s4dom.net. > KDC send TGS response with Realm in TGT2 being equal to hostname in TGT2 > (s4dom.net in this case) and the expression mentioned above evaluates to > FALSE and no referral loop is detected. > > You probably know it already, but I'll mention it just for completeness. I > can login by using administra...@s4dom.net on WS2k3 client when KDC is Samba. Yep, and it gave me great relief that it wasn't something more fundamental, but we have some proprietary products running on Windows that seem to trigger the alternate login, which is what was getting us stuck. > I’ll update you as soon as I have the changes in the document. Please let me > know if it answers your question. 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
Re: [cifs-protocol] [REG: 111020250601482 ] RE: Please provide windows behaviour notes on MS-KILE's reference to Referrals-11
On Wed, 2011-02-02 at 20:09 +, Obaid Farooqi wrote: > Hi Andrew: > I'll help you with this issue and will be in touch as soon as I have an > answer. Is there any news on this in the past week? Unlike my typical pattern, I thought it best to put off trying to rectify this area until I got some information. Can you give me an idea when you will be able to shed some light on this area? 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
[cifs-protocol] Please provide windows behaviour notes on MS-KILE's reference to Referrals-11
I'm trying to understand Microsoft's behaviour around referrals to trusted domains, and referrals as generated between the NetBIOS and DNS names for a domain. I think this is meant to be covered by http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-11 referred to as Referrals-11 in MS-KILE. However, what I really need is some detail on exactly how Microsoft implements it, as sadly I have little confidence that Windows 2003 follows exactly an RFC proposal last dated in 2008 :-) Presumably these need to be addressed in Windows behaviour notes. In particular, I'm looking at the example archived here: http://permalink.gmane.org/gmane.network.samba.internals/53515 The issue in this case is that the user logs in with DOMAIN\user and Samba attempts to transform that into user@REALM, but the client does not appear to accept the cross-realm ticket (to ourselves) that we generate. Any assistance you can give would be most welcome. 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
Re: [cifs-protocol] [REG:110122106325012] [MS-DNSP] Documentation for DNS_TYPE_ZERO (was "strange records in DNS LDAP NCs")
On Tue, 2011-01-04 at 17:36 +, Bryan Burgin wrote: > Hi Tridge, > > Happy new year. I'm checking to see if you had any additional feedback on > this or if you received the information you needed. Bryan, I think you are misunderstanding the context here. We have found these records in Active Directory, in the DNS application naming contexts: Andrew Tridgell wrote: > There are a few aspects of the Windows DNS NCs that are puzzling us: > > 1) we see records like this: > > dn: > DC=..SerialNo-W2K8R2B.v2.tridgell.net,DC=v2.tridgell.net,CN=MicrosoftDNS,DC=DomainDnsZones,DC=v2,DC=tridgell,DC=net > dnsRecord: NDR: struct dnsp_DnssrvRpcRecord > wDataLength : 0x0008 (8) > wType: DNS_TYPE_ZERO (0) > dwFlags : 0x0005 (5) > dwSerial : 0x02b1 (689) > dwTtlSeconds : 0x (0) > dwTimeStamp : 0x (0) > dwReserved : 0x (0) > data : union dnsRecordData(case 0) > data : DATA_BLOB length=8 > [] 40 47 30 F4 9F A0 CB 01@G0. > > what are they for? What is in that 8 bytes of data? What is the significance > of the "..SerialNo-HOSTNAME" records? > > The MS-DNSP doc says: > >DNS_TYPE_ZERO An empty record type (section 3.6 in [RFC1034] and > section 3.2.2 in [RFC1035]). >0x > > which isn't very useful! > > 2) what is the dwReserved field in all the dnsNode records? The MS-DNSP doc > says: > >dwReserved: This value MUST be set to 0x when sent by the client > and ignored on > receipt by the server. > > but that makes no sense. These are fields that are sent by the LDAP or > DRS server in response to queries. The values are far too consistent > to be random. > > Note that we are not asking about the DNS RPC protocol that MS-DNSP > concentrates on. In our case Samba is a DC that is replicating the DNS > NCs with Microsoft DCs. We need to know how to fill in these fields > when we create records that will be replicated to MS DNS servers via > DRS. > > Cheers, Tridge -- 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
Re: [cifs-protocol] Please describe MS-LSAD 2.2.4.19 AuthenticationOptions
On Thu, 2010-12-09 at 13:35 +1100, Andrew Bartlett wrote: > On Thu, 2010-12-09 at 12:09 +1100, Andrew Bartlett wrote: > > MS-LSAD 2.2.4.19 states: > > > > AuthenticationOptions: Optional flags that affect validations performed > > during authentication. > > > > What are these optional flags, where and how are they stored, and what > > do they do? > > I was put off by the document formatting. All the information I need is > there and in MS-KILE. ...almost all. I need the actual value for the bitfield. Can you please include the constant value in hexadecimal for POLICY_KERBEROS_VALIDATE_CLIENT I presume it is 0x0080. Thanks. -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please describe MS-LSAD 2.2.4.19 AuthenticationOptions
On Thu, 2010-12-09 at 12:09 +1100, Andrew Bartlett wrote: > MS-LSAD 2.2.4.19 states: > > AuthenticationOptions: Optional flags that affect validations performed > during authentication. > > What are these optional flags, where and how are they stored, and what > do they do? I was put off by the document formatting. All the information I need is there and in MS-KILE. (I only noticed it when I asked google about the flags, and found where I asked about it last time...) Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] Please describe MS-LSAD 2.2.4.19 AuthenticationOptions
MS-LSAD 2.2.4.19 states: AuthenticationOptions: Optional flags that affect validations performed during authentication. What are these optional flags, where and how are they stored, and what do they do? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] cifs client timeouts and hard/soft mounts
On Sat, 2010-12-04 at 09:12 +0100, Volker Lendecke wrote: > On Fri, Dec 03, 2010 at 09:28:11PM -0500, Jeff Layton wrote: > > So, what does this mean for CIFS clients? I believe that the best > > behavior for the client is to *never* time out an individual request, > > aside from SMB echoes. > > I like this concept. +1 If the server is up and running enough to respond with smb echo replies, then it seems reasonable to assume it is still dealing with the other requests, or if it wishes to abandon a pending request, it will respond to it (eventually) with an error. Volker, Is it correct to say that this is how Samba3 deals with slow calls and Windows clients, using the echo handling child? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110110481276509] Please include bitfield names in MS-NRPC LogonParameters
On Tue, 2010-11-09 at 23:27 +, Bryan Burgin wrote: > Andrew, > > Your response “The behaviour of these items is not well documented > here, but is elsewhere, but without the constant values. Using the > correct names allows us to tie in different sources of information” > was helpful. I filed a request with the documentation group to > consider your feedback. Attached is a mock-up of [MS-NRPC] 2.2.1.4.15 > NETLOGON_LOGON_IDENTITY_INFO’s ParameterControl I provided them to > illustrate your request. > > I will update you when I get a response from the PG. Since this is > documentation feedback, I intend to close this incident if I properly > captured your request. Yes, that would provide the improvement I desire. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110110481276509] Please include bitfield names in MS-NRPC LogonParameters
On Fri, 2010-11-05 at 21:51 +, Bryan Burgin wrote: > Hi Andrew. > > Is the absence of the Windows-specific variable names blocking your > development? Yes, in a way. The behaviour of these items is not well documented here, but is elsewhere, but without the constant values. Using the correct names allows us to tie in different sources of information. > There may be push back to do so since this is in the normative section > of the document. I agree that it seems like a helpful suggestion. Is > there an argument I can present on your behalf to show a reason that > doing so is required to implement the protocol. > > As for adding the hex values, I'm prepared to make that request. Frankly, I don't understand why the name cannot be included, as it is in so many other places? For example, MS-SAMR 2.2.1.12 USER_ACCOUNT Codes Given that the fundamental purpose of these documents is to help, rather than hinder, the development of interoperable implementations, what is the argument against including the normative and traditional names for the bits? On the same argument you could rewrite the IDL to be a series of 'member1, member2', with verbose descriptions but no rational names. Using common, existing names helps developers achieve interoperability because it enables clear and effective communication between all the parties, including in particular parties that have had to rely on other Microsoft documents released before and alongside the WSPP program, and therefore should form part of the normative description of the protocol. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110110481276509] Please include bitfield names in MS-NRPC LogonParameters
On Fri, 2010-11-05 at 17:53 +, Bryan Burgin wrote: > Hi Andrew. > > I can help you with this. > > My understanding that this is a continuation of the issue you > discussed in the past where we would add the hex value of each bit > field to improve readability and make searching easier. Is that > correct? For example, the table entry for 2.2.1.4.15's > ParameterContol "Value A", "Clear text passwords can be transmitted > for this logon identity" would also list that its hex value as > 0x0002. > > If my understanding is correct, I'll proceed with making the documentation > request. If you are requesting a different outcome, please let me know. The > recommendation would add a new column as follows: Almost, I also need name names from the referenced URL included. > A: 0x0002: Clear text passwords can be transmitted for this logon > identity. > B: 0x0004: Update the logon statistics for this account upon successful > logon. > C: 0x0008: Return the user parameter list for this account upon > successful logon. > D: 0x0010: Do not attempt to log this account on as a guest upon logon > failure. > E: 0x0020: Allow this account to log on with the domain controller > account. > F: 0x0040: Return the password expiration date and time upon successful > logon. > G: 0x0080: Send a client challenge upon logon request. > H: 0x0100: Attempt logon as a guest for this account only. > I: 0x0200: Return the profile path upon successful logon. > J: 0x0400: Attempt logon to the specified domain only. > K: 0x0800: Allow this account to log on with the computer account. > L: 0x1000: Disable allowing fallback to guest account for this account. > M: 0x2000: Force the logon of this account as a guest if the password is > incorrect. > N: 0x4000: This account has supplied a clear text password. > O: 0x0001: Allow NTLMv1 authentication ([MS-NLMP]) when only NTLMv2 > ([NTLM]) is allowed. > P: 0x0010: Use sub-authentication ([MS-APDS] section 3.1.5.2.1). > Q-X: 0xFF00: Encode the sub-authentication package identifier. Bits Q–X > are used to encode the integer value of the sub-authentication package > identifier (this is in little-endian order). eg: A: 0x0002: MSV1_0_CLEARTEXT_PASSWORD_ALLOWED: Clear text passwords can be transmitted for this logon identity. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] Please include bitfield names in MS-NRPC LogonParameters
In 2.2.1.4.15 NETLOGON_LOGON_IDENTITY_INFO we have the description of LogonParameters. These values have well-known names, see http://msdn.microsoft.com/en-us/library/aa378767%28VS.85%29.aspx Can you please include these names an in particular the associated values in the WSPP docs, so that we can find the documentation without manually parsing the bit-field? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] krbtgt key to sign PAC with on an RODC
If a RODC signs the PAC with the krbtgt key of the RODC, how is this marked in the PAC, so that another DC can verify the PAC if presented over NetLogon? MS-PAC 2.8.2 KDC Signature does not make this very clear. Does a RODC not provide this signature, as it can't get a the krbtgt key, or does it use it's own krbtgt? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group
On Mon, 2010-08-23 at 23:37 +, Hongwei Sun wrote: > Tridge/Andrew, > >I have been testing and debugging the Windows behavior related to > tokenGroups rootDSE attribute in RODC. It seems that I cannot duplicate what > you have observed. I have a RODC joined to a domain that has two more > RWDCs. I got the following output for the rootDSE in RODC object and RootDSE > when I did a base search to the RODC from another DC in the same domain. > They don't include RID 498. > > Dn: (RootDSE) > tokenGroups (16): > S-1-5-21-3071076805-1052773752-2226054901-500; > S-1-5-21-3071076805-1052773752-2226054901-513; > S-1-1-0; > S-1-5-32-544; > S-1-5-32-545; > S-1-5-32-574; > S-1-5-32-554; > S-1-5-2; > S-1-5-11; > S-1-5-15; > S-1-5-21-3071076805-1052773752-2226054901-512; > S-1-5-21-3071076805-1052773752-2226054901-520; > S-1-5-21-3071076805-1052773752-2226054901-519; > S-1-5-21-3071076805-1052773752-2226054901-518; > S-1-5-21-3071076805-1052773752-2226054901-1103; > S-1-5-21-3071076805-1052773752-2226054901-572; You have connected as the wrong user. We joined a Windows RODC to the domain, then changed it's password, and ran ldbsearch *as* the RODC, using the password we set on it's account. You have run the search as administrator, and natrually returned the tokenGroups for administrator. > --- > ***Searching... > ldap_search_s(ld, "CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com", > 0, "(objectclass=*)", attrList, 0, &msg) > Getting 1 entries: > Dn: CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com > tokenGroups (2): S-1-5-21-3071076805-1052773752-2226054901-572; > S-1-5-21-3071076805-1052773752-2226054901-521; When you connect as the RODC, you should see these SIDs, and the extra ENTERPRISE_RODCs group in the rootDSE tokenGroups. I'm sorry I didn't respond earlier - I simply didn't see your mail! Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2
On Thu, 2010-07-08 at 11:43 +, Bill Wesse wrote: > Resending the DumpSchema.cmd(.txt) file; I broke the earlier one during an > edit (deleted a label ':Perform'). Sorry. Dochelp. I was working on this with Bill, but I need to bump this a long a little, and to clarify things a bit more: It is great having commands to dump the schema - we can write such commands easily, and use those to confirm that the schema we supply to our users is correct. Indeed, such commands have shown that we have not been supplied correct schema in the past. However, what I need isn't tools to extract schema from AD servers, but the actual schema, provided by Microsoft to us under the agreed licence. This makes it unambiguous that we can redistribute the result. Therefore, we do require the schema from the WSPP documentation, we require it in a format that is suitable for use in creation of an interoperable implementation, we need is under the licence, and we require that it is 100% correct. If we cannot get those assurances, we have two problems: We waste an inordinate amount of time fixing bugs that should never have occurred (surely the docs were generated with tools such as you supplied in your mail), and we loose confidence that any update to the schema or a new revision is correct. Have you had any luck securing those assurances from the product group? It seems to have taken quite some time, for something that should be nothing more than providing an automated extract. Thankyou, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2
On Thu, 2010-07-08 at 11:43 +, Bill Wesse wrote: > Resending the DumpSchema.cmd(.txt) file; I broke the earlier one during an > edit (deleted a label ':Perform'). Sorry. Bill, Perhaps I need to explain: It is great having commands to dump the schema - we can write such commands easily, and use those to confirm that the schema we supply to our users is correct. Indeed, such commands have shown that we have not been supplied correct schema in the past. However, what I need isn't tools to extract schema from AD servers, but the actual schema, provided by Microsoft to us under the agreed licence. This makes it unambiguous that we can redistribute the result. Therefore, we do require the schema from the WSPP documentation, we require it in a format that is suitable for use in creation of an interoperable implementation, we need is under the licence, and we require that it is 100% correct. If we cannot get those assurances, we have two problems: We waste an inordinate amount of time fixing bugs that should never have occurred (surely the docs were generated with tools such as you supplied in your mail), and we loose confidence that any update to the schema or a new revision is correct. Have you had any luck securing those assurances from the product group? It seems to have taken quite some time, for something that should be nothing more than providing an automated extract. Thankyou, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] How to RODCs get their membership of the ENTERPRISE_RODCs group
We are working on having Samba support having Win2k8 servers as read only domain controller in the Samba4 domain. We noticed that RODCs are given primaryGroupID of 521 - the RODC group for the local domain. This happens when they join over LDAP (we can't find the documentation for this either, but it's clear from our testing). However, all the documentation talks about RODCs being a member of the enterprise read only domain controller group - which has a RID of 498. How is the 498 implied from the 521? There isn't a member link between the groups for example. Is it simply linked during token construction somehow? It also does not appear in the tokenGroups of the RODC account over LDAP (as found in a base search on the RODC object). tokenGroups: S-1-5-21-3565189888-2228146013-2029845409-572 tokenGroups: S-1-5-21-3565189888-2228146013-2029845409-521 However, it does show up in the tokenGroups in the rootDSE, if we connect *as* the RODC tokenGroups: S-1-5-21-3565189888-2228146013-2029845409-1116 tokenGroups: S-1-5-21-3565189888-2228146013-2029845409-521 tokenGroups: S-1-1-0 tokenGroups: S-1-5-32-554 tokenGroups: S-1-5-32-545 tokenGroups: S-1-5-2 tokenGroups: S-1-5-11 tokenGroups: S-1-5-15 tokenGroups: S-1-5-21-3565189888-2228146013-2029845409-498 tokenGroups: S-1-5-21-3565189888-2228146013-2029845409-572 tokenGroups: S-1-5-64-10 Can you please explain how we are meant to get from one to the other? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110062157456375] -[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
On Fri, 2010-07-09 at 20:53 +, Bryan Burgin wrote: > Andrew, > > > > I received the following response from the product group, which I am > forwarding for your feedback. Please let me know if this resolves > your question. Not really, because I can't really map the response back to my question, and because of the silly practice of documenting Microsoft-specific exceptions (<28> and <31>) to a Microsoft specific protocol. What are those exceptions, and why can't they be described inline? > [MS-KILE] Section 3.3.1.1 “Account Database Extensions” specifies the > account database extension which impacts KDC behavior: > > > > KerbSupportedEncryptionTypes: A 32-bit unsigned integer that contains > a combination of flags that specify what encryption types (section > 2.2.5) are supportedby the application server.<24> KILE > implementations that use an Active Directory for the accountdatabase > SHOULD use the msDS-SupportedEncryptionTypes attribute ([MS-ADA2] > section 2.324). > > > > [MS-KILE] Section 3.3.5.3 “AS Exchange” specifies the behavior during > AS_REQ processing: > > > > If the krbtgt account has a KerbSupportedEncryptionTypes populated > with supported encryption types, then the KDC SHOULD<28> return in the > encrypted part ([Referrals-11], Appendix A) of AS-REP message PA-DATA > with padata-type set to PA-SUPPORTED-ENCTYPES(165), to indicate what > encryption types are supported by the domain KDCs. KerbSupportedEncryptionTypes is msDS-SupportedEncryptionTypes? Also, how exactly is the key available for encryption of the krbtgt ticket calculated (rather than the PA-SUPPORTED-ENCTYPES(165) value, which is multi-value). > If not, the KDC SHOULD check if the krbtgt account has the UseDESOnly > flag and if set to: > > § TRUE: the KDC SHOULD, in the encrypted pre-auth data > part ([Referrals-11], Appendix A) of the AS-REP message, include > PA-DATA with the padata-type set to PA-SUPPORTED-ENCTYPES (165), and > the padata-value set to 0x3 (Section 2.2.5). > > § FALSE: the KDC SHOULD, in the encrypted pre-auth data > part ([Referrals-11], Appendix A) of the AS-REP message, include > PA-DATA with the padata-type set to PA-SUPPORTED-ENCTYPES (165), and > the padata-value set to 0x7 (Section 2.2.5). So, to get this a little more concrete we only encrypt krbtgt with AES msDS-SupportedEncryptionTypes only if that is specified for krbtgt and that enc type is included in msDS-SupportedEncryptionTypes? Why do you allow krbtgt tickets to be encrypted between KDCs with only des-cbc-md5 encryption? Does this not allow a trivial brute-force attack on the all-important krbtgt password? > [MS-KILE] Section 3.3.5.4 “TGS Exchange” specifies the behavior during > the TGS_REQ processing: > > > > If the server or service has a KerbSupportedEncryptionTypes populated > with supported encryption types, then the KDC SHOULD<31> return in the > encrypted part ([Referrals-11] Appendix A) of TGS-REP message PA-DATA > with padata-type set to PA-SUPPORTED-ENCTYPES (165), to indicate what > encryption types are supported by the server or service. If not, the > KDC SHOULD<32> check the server or service account's UseDESOnly and if > set to: > > § TRUE: the KDC SHOULD, in the encrypted pre-auth data > part ([Referrals-11], Appendix A) of the TGS-REP message, include > PA-DATA with the padata-type set to PA-SUPPORTED-ENCTYPES (165), and > the padata-value set to 0x3 (Section 2.2.5). > > § FALSE: the KDC SHOULD, in the encrypted pre-auth data > part ([Referrals-11], Appendix A) of the TGS-REP message, include > PA-DATA with padata-type set to PA-SUPPORTED-ENCTYPES (165), and the > padata-value set to 0x7 (Section 2.2.5). I'm still a little lost as to how this applies to what keys are available for AS-REQ and TGS-REQ on and to a given account. Is the actual behaviour much more like: - the supported encryption types displayed over the Kerberos protocol is calculated from the intersection of the keys available and the msDS-SupportedEncryptionTypes value (or fallback value based on UseDESOnly) (The keys available are of course limited by the domain functional level that controls what encryption types are written on password change) Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2
On Thu, 2010-07-01 at 17:21 +, Bill Wesse wrote: > A quick update: Confirmation on time/dates of the latest schema text > files will be forthcoming after the July 6 meeting I mentioned below. > Sorry I won't be able to confirm before that. Thanks again for your > patience... No worries. I would rather wait until you have absolute confidence that these schema files match the schema in Windows than spend time debugging why they don't match. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110062452298172] Text-file Schema for all of 2000-2008R2
On Wed, 2010-06-30 at 11:57 +, Bill Wesse wrote: > Hi Andrew. I am advised that a planning meeting including the topic of > where we intend to post the schema text files is scheduled for next > Tuesday (July 6). I will advise you on the results as soon as I can > after that (it is occurring very late in the day, my time). OK. Please just post them in a reply to cifs-protocol in the meantime. > Meanwhile, I am currently waiting for confirmation on the latest file > dates for the schema files we have provided. I expect to have that > info within the next day or so. OK. Can you give me some indication as to your level of confidence that the latest files match what is actually found in the respective AD versions? I just want to set my expectations correctly before I start trying to have Samba load them. > Also, there are some limits on our support level for the schema text > files – I will also advise you on that (query in progress…). I'm sorry to hear about the limitations on the support for the schema files. We only ask for them because we found the PDF documents to be both inaccurate and unusable for the purpose for which they purport to be provided (the creation of interoperable implementations). We do appreciate the extra effort that has gone into providing them, and getting them under an acceptable licence, but it is only by the provision of text-format schema that we have been able to show how deficient the documentation has been in the first place. I still don't understand how so many errors crept into a document that should be no more than a reformat of a direct extract from the version control system for the relevant AD versions. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2
On Tue, 2010-06-29 at 09:06 +, Bill Wesse wrote: > Thanks Andrew. > > Richard's mail of Apr 24 2009 > (http://lists.samba.org/archive/cifs-protocol/2009-April/000740.html) > contained schema text that has definitely been superseded by the ones > I sent you yesterday. I am *fairly* sure those I send yesterday are > the latest & greatest, and should know for sure later today. > > Thanks for offering to end the patches / ldapcmp tool - for the > moment, that won't be necessary. OK. Do at least use source4/scripting/python/samba/ms_schema.py - it will save you a lot of time trying to turn these back into ldif you might have a hope of comparing with a real server. > Do you have Richard's attachment to fwd back to me? I'm already up to > quite a few file collections, and should first diff what he sent > against what I sent before thinking about proceeding further. The links to those are in the archive links I posted. > It's Ok with me to keep cifs-protocol in the loop. I may have to do > that manually on any responses, I'm not sure if our incident > management software can target outbound emails to multiple addresses > (it's evolving, and I've been offline from it for ~2 months). > I am also awaiting confirmation for posting those latest schema text > files to our team blog. That should happen by early next week. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] Text-file Schema for all of 2000-2008R2
A while back, Richard Guthrie worked with us to get us text-file schema for AD. I'm currently trying to import the schema for 2000, 2003 and 2003R2 to assist our testing. The most recent files I have are Schemas.zip and SchemaFiles.zip, both posted by Richard to this list. This was followed up with further discussion with Hongwei earlier this year in SRX090109601490 to no result. Out of all this, we have self-consistent schema for 2000, 2008 and 2008R2, but this schema does *not* match that on a Microsoft server, and 2003 and 2003R2 schemas we have do not load in our parser. Before I investigate this further, and before we start again on a long series of 'fix one silly typo at a time' in what should have been autogenerated files, can I ask: What is the canonical location for the text format schema files for AD, that are the input to the WSPP set? If there is not a web location, can I get by e-mail a full validated set in the format matching what we have in our tree: http://gitweb.samba.org/?p=samba.git;a=tree;f=source4/setup/ad-schema;h=06d2fe30e4f55412a6262b64a6bb2912d9dafa33;hb=HEAD Thanks, Andrew Bartlett ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
On Mon, 2010-06-21 at 22:54 +, Hongwei Sun wrote: > Andrew, > > Sorry about the delay to give you a confirmation. No worries. > We have been spending time to review the usage of UserParameters in > other Windows components based on the information you provided. We > found that this attribute is indeed still used by at least one other > Microsoft product, such as RAS Server. The related product team is > working on this to find how to document it. During my vacation, I > will ask one of my team member (Obaid) to monitor the progress and > send you the update when it is available. Isn't software archeology fun! Enjoy your break, and don't stress about this one too much. I look forward to seeing a final breakdown of the structure some day, to help those trying to write user management tools for Samba4. Thanks, Andrew Bartlett ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
On Mon, 2010-01-25 at 16:44 +, Bill Wesse wrote: > 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. I've just started looking at this area again, and am very glad to have found this thread, because I think there needs to be a few more links or references here. There is no information in MS-KILE to indicate that this attribute changes KDC behaviour, for example. Where should I look to understand how this attribute changes the KDC, other than the blog post (which is not precise regarding differences between AS-REQ and TGS-REQ use of the keys)? Thanks, Andrew Bartlett ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
On Tue, 2010-06-01 at 22:51 +, Hongwei Sun wrote: > Andrew, > >This 96 bytes unused data is not currently used by Terminal Service. The > following is the update to the documentation: > >UnusedData (96 bytes): A 96 byte array of unused data. This array is > filled with the ASCII character for space (0x20). So I take it that the 'dial back number' stuff no longer exists? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
On Wed, 2010-05-26 at 23:07 +, Hongwei Sun wrote: > Andrew, > >We have confirmed that currently "UserParameter" attribute is only used by > the Terminal Service and there is no any other Microsoft product that also > uses this attribute. The Terminal Service doesn't use the first 96 bytes of > the "UserParameter" attribute. In order to avoid any confusion, we will > rename "MSProductData" to "UnusedData" in the 2.3.1 of the future release of > MS-TSTS. > >Please let us know if you have any more question, if not, I will consider > this case closed. That's weird. For ages, this was referred to in samba as the 'munged dialback field', because (from memory) the first part was meant to contain the phone number to call back for old-style modem-callback security. I take it that this does not exist any more? For reference, we finally got rid of the field in this commit: http://www.mail-archive.com/samba-...@lists.samba.org/msg49021.html UNISTR2 uni_munged_dial ; /* munged path name and dial-back tel no */ Where the field after 'comment' on SAM_USER_INFO_23 became 'parameters' from the IDL. This 'parameters' maps to userParameter in LDAP. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
On Tue, 2010-04-13 at 18:18 +, Hongwei Sun wrote: > Tridge, > >I just want to check with you to see if you have any question regarding > the newly added documentation for this attribute. If not, I will close this > CAR. The reference is good, but it seems there is a problem because of the way this parameter is split between products. In particular, while this may be true for MS-TSTS: [MS-TSTS] 2.3.1 UserParamerters: MSProductData (96 bytes): A 96 byte Unicode character array containing 48 Unicode characters. This field is not used by Microsoft Terminal Services. We need to know the full decode of the structure, regardless of which product or document owns it. In short, what is the meaning and expected contents of MSProductData? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
On Tue, 2010-04-13 at 18:18 +, Hongwei Sun wrote: > Tridge, > >I just want to check with you to see if you have any question regarding > the newly added documentation for this attribute. If not, I will close this > CAR. Can you make sure this information is referenced from the schema docs and available under WSPP? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] Thankyou for returning the bitfield values!
Tridge recently pointed me at the return of hexadecimal constants in bitmask definitions. I'm so glad these are back - it will make interruptibility much easier, and the conversations we have here much more reliable. As you know, the challenges here have been a pet gripe of mind for a number of years now. Please pass on my thanks to everybody that has been involved in fixing this! Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
On Sat, 2010-02-13 at 00:32 +, Hongwei Sun wrote: > Thanks for the clarification! It helps a lot. Do you mean "identical" > to the Windows 2008 R2 schema implemented on a windows DC ? Yes. > Does "Exact Value comparison" mean to compare the elements between > the schema file we sent you and a real Windows 2008 R2 schema ? Yes, after post-processing. We have scripts that convert from the textual flags (fINDEXATTR etc) to bit flags. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
On Fri, 2010-02-12 at 22:55 +, Hongwei Sun wrote: > Tridge/Andrew, > > We are in the process to update our MS-ADA* documents to reflect all the > changes you made to the schema. I just want to confirm how you got these > changes and if all these changes are essential. Your comments in diff below > mentioned only the typos. > > "The schema from WSPP had a number of typos that prevented it from > working. These changes allow it to work with Samba, and allow w2k8r2 > to run DCPROMO against Samba successfully" > > How about the other changes, especially all these attributes adding > SystemFlags: 0 ? If you don't have these changes, does it affect the > functionality of W2k8 R2 to join Samba domain ? Have you got the > other changes by comparing with an existing W2k8R2 schema ?The > following is the list of attributes that affect schema documents. We didn't do this as a 'does this make things break', but as 'what is required to make the schema come out identical again'. We don't trust that we can write tests that can prove that a different schema is equivalent for all client software, so instead we go for exact value comparison. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] What elements of the DIT are required for AD to operate?
On Thu, 2010-01-21 at 23:20 +, Hongwei Sun wrote: > Andrew, > >I attached the file with the list initially required DIT elements > for Windows 2008R2 function level. All the required DIT elements > should be all documented in section 7 of MS-ADTS. Therefore , we > manually reviewed the LDIF dump of a DC and compared with MS-ADTS to > decide which elements should be kept. Please review it and give us > feedback. Thanks! We look forward to testing this out. What I'm wondering is how did you verify that an element was not required - just that it isn't mentioned in the doc, or did you delete it from a running windows DC and try repetitive DCpromo (or something else)? Do you have a list of the DN values that may be found in the normal provision of a Windows DC that are not required (ie, those you removed)? If you have this, it would help our validation by being able to look at this from both directions. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Structure of prefixMap over LDAP
On Thu, 2010-01-14 at 18:26 +, Obaid Farooqi wrote: > Hi Andrew: > Please let me know if the following answers your question. If yes, I'll > consider this issue resolved. I'm waiting on Kamen to implement this in Samba4 to verify the resolution. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
On Mon, 2010-01-11 at 20:51 +, Hongwei Sun wrote: > Andrew, > > At this moment, I am now going through the diff reports pointed by Tridge. > > > For adminDescription and adminDisplayName, it looks like that they are > already included in the schema file (MS-AD_Schema_2K8_R2_Attributes.txt). > Have I missed something ? Sure, I'm not asking for their definitions, but for them to be filled with the appropriate data for each schema object. (otherwise we cannot reconstruct what is visible on LDAP) Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
On Mon, 2010-01-11 at 15:23 +, Hongwei Sun wrote: > Andrew, > > Most of the issues mentioned in your mail have been fixed in the latest > released MS-ADSC or MS-ADA3. The following is a summary. > The schema of Windows 2008 R2 we sent you in 04/24/2009 doesn't > incorporate the above changes. I will work on it. We do have tools/scripts > to create and validate the schema. Is there a location where you continually post the text file version of the schema, or do we have to ask each time? Also, have you addressed the issues tridge mentioned in his reply, and the adminDescription/adminDisplayName issue? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
On Sat, 2010-01-09 at 07:04 +1100, tri...@samba.org wrote: > Hi John, > > You can see the patch against the W2K8-R2 schema here: > > > http://build.samba.org/?function=diff;tree=samba_4_0_test;date=1262935494;revision=ad11deb9bd825d699e2b6799b40d98c28c95910e > > These were the changes that we made to allow the schema from WSPP to > operate correctly with a W2K8-R2 windows client joining a Samba domain > using DCPROMO. > > As Andrew mentioned, the curious thing is that there were some obvious > typos in the schema (eg. isRecycled -> isRecyled). Perhaps you could > test the schema file for a future release by comparing it to schema on > a windows box? Also, could we please have the adminDescription and adminDisplayName included in the schema? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
On Fri, 2009-04-24 at 09:07 -0700, Richard Guthrie wrote: > Andrew: > > Attached are schema files for Windows 2008 and Windows 2008R2/Windows 7. The > Windows 2008 schema should not have any issues based upon initial validation > against the Windows 2008 schema. The release notes for the Windows > 2008R2/Windows 7 schema are as follows (All issues are under investigation at > this time): > > 1. cn: Computer - Schema pulled from Windows 2008R2 shows two additional > attributes for systemMayContain msTSSecondaryDesktopBL, msTSPrimaryDesktopBL. > These are not present in the latest documentation for this attribute. > 2. cn: Domain-DNS - defaultSecurityDescriptor in does not match the schema > pulled from Windows 2008R2 3. cn: inetOrgPerson - defaultSecurityDescriptor > does not match the schema pulled from Windows 2008R2 4. cn: Object-Class - > searchFlags do not match the schema pulled from Windows 2008R2 5. cn: > Sam-Domain - defaultSecurityDescriptor does not match the schema pulled from > Windows 2008R2 6. cn: Schema - This attribute may be missing from the schema > documentation. It shows up in the Windows 2008R2 schema so it is being > investigated. > 7. cn: Top - There appears to be a discrepancy with the generated Windows > 2008R2 schema and the documented schema for systemMayContain attribute. Dear Dochelp, Did anyone ever solve these, and can I get a correct file for the final release of Windows 2008 R2? Do you have a script to validate these? We are finding far more errors than just the above (diff to follow shortly), as it seems these files are still generated by hand (why?!?) Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] How do we know what attributes are OIDs, classes and attributes
G'day In LDAP, it is convention to display attribute names and classes as strings, except of course for governsID and attributeID. In DRS, these attribute and class names are transformed (using the prefix map) into 32 bit integers. What we need to know is, how should we tell if an attribute should be displayed in LDAP as an OID (dotted decimal), or as an attribute or class name. My worry is that this can't be handled as just 'schema only' and 'hardcoded list', because it is clearly possible to add OID syntax (2.5.5.2) attributes to objects in the general directory. For example: dn: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=my,DC=domain transportAddressAttribute: dNSHostName How should I know that transportAddressAttribute must be displayed as a text string, and not an OID? How should I know that I display governsID as an OID? Are all attributes of syntax OID (2.5.5.2) transported over DRS as integers, or is there a hardcoded list? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] RID Allocation behaviour
G'day Tridge and I are working on Samba4's implementation of the distributed RID allocation. We are unclear on a number of aspects of the expected behaviour, particularly when the RID manager is not the DC adding users. I'll describe this in terms of the 'RID manager DC' and the 'remote DC' For example: It appears that the Remote DC is responsible for updating the ridNextRID attribute, but rather than storing the next RID, it appears to store the last allocated RID. The actual remote DC allocation process for RIDs appears undocumented. It appears the RID Manager DC is responsible for updating the rIDAllocationPool for each DC, and the rIDAvailablePool. We think the remote DC is responsible for ridPreviousAllocationPool and allocates RIDs from that pool, but this is only described in the schema doc. Any light you can shed on this process would be most appreciated. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Structure of prefixMap over LDAP
On Tue, 2009-12-15 at 06:22 +, Obaid Farooqi wrote: > Hi Andrew: > In an effort to fully understand your goals, please explain what you are > looking > to achieve through the addition of documentation that defines the internal > structure of the prefixMap attribute. As a start: The ability to generate a matching prefixMap attribute, should any client request it. The ability to verify prefixMap values over DRS and LDAP to confirm consistency. The ability to include prefixMap values in comparison tests we may make between AD and Samba4. An understanding of how the contents of this attribute interacts with msDs-intID and other prefix mapping functionality. Finally, I'm simply looking to ensure that the documentation set explains the format of every value (generated or otherwise) in AD, so we don't have to come back to this later. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Structure of prefixMap over LDAP
On Fri, 2009-12-11 at 20:09 +, Obaid Farooqi wrote: > Hi Andrew: > We have finished our investigation on your question regarding > prefixMap appearing on the wire. > > PrefixMap is an attribute specific to Microsoft's Active Directory > implementation. It is used by the system to map an internal structure > to its corresponding OID. PrefixMap resides in the directory and, as > a consequence, can be retrieved via LDAP by using any LDAP-capable > tool such as LDP or LDIFDE. > > PrefixMap does not appear on wire for any LDAP protocol related > messages. Microsoft LDAP implementation do not access or use the > attribute over wire. It only appears on the wire when explicitly > requested. Obaid, That does not answer my question. As long as it appears over LDAP, it must be documented. There are many aspects of many protocols that only show up with non-default parameters. That does not make these things distinct from the protocol. As such, can you please document the format of prefixMap. Thank you. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] 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. 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] What elements of the DIT are required for AD to operate?
G'day, In the last few months, we have had great success with joining a Window 2008 R2 server into a Samba4 hosted domain. It was a great achievement, and the speed of development we achieved over this difficult area is a testament to the support we received at the plugfest. However, that success was only possible when we have first joined Samba4 to an already operational Active Directory domain, and obtained the full database over DRS replication. Samba aims for and requires a high standard of interoperability - a standard of 'either Samba or Windows must be able provision/initialise the domain, without clients or other domain controllers seeing the difference'. However, during the development last week we also found out (by painful experience and in discussion with your developers) that Windows performs very few checks on the incoming replicated data, and is not tolerant of deviations from the expected form. So, to achieve this interoperability, we need to know precisely what things a windows domain controller needs across the directory replication channel, for it to become and operate correctly as a domain controller. Put another way: what are the required DIT elements for a server to provision to be the initiator of an Active Directory forest? We do already have many of these elements implemented - things like the Display Specifiers and Schema we were very glad to obtain earlier - but it seem there is much more required. Much of this is in the documentation set - particularly MS-ADTS, but scattered in a way that makes for a great reference, but a poor source for implementation (because it is so easy to miss one). My hope is that like the schema and display specifiers, that this information (effectively the minimum initial DIT) can also be made available to us in a similar, machine-readable fashion, for each supported functional level. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] primaryGroupToken
MS-ADA3 2.120 claims: Attribute primaryGroupToken This attribute specifies a computed attribute that is used in retrieving the membership list of a group such as Domain Users. The complete membership of such groups is not stored explicitly for scaling reasons. For more information refer to [MS-ADTS] section 3.1.1.4.5.11 and [MS-SAMR]. However, MS-ADTS 3.1.1.4.5.11 claims: primaryGroupToken Let TO be the object from which the primaryGroupToken attribute is being read. The value of TO!primaryGroupToken is the RID from TO!objectSid when there exists C in TO!objectClass such that C is the group class. Otherwise, no value is returned. That is, if TO is a group, then the value of this attribute is the RID from the group's SID. If TO is not a group, no value is returned when this attribute is read from TO. The behaviour of Window 2008 appears to follow MS-ADTS. That is, the primaryGroupToken appears to be the RID of the objectSID for all groups. Please advise, clarify or correct, Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
On Fri, 2009-11-20 at 18:02 +, Bill Wesse wrote: > Good morning Andrew - I am resending this email from November 4. I did get the message, but was surprised by the contents and I've been unable to find the time to verify it. > -Original Message- > From: Bill Wesse > Sent: Wednesday, November 04, 2009 12:22 PM > To: 'Andrew Bartlett' > Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter > Wallnöfer' > Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor > (SRX090727600015) > > Good morning Andrew - I am resending this email from October 29. > > Please let me know if this answers your question satisfactorily; if so, I > will consider your question resolved. > > The actual updates for Validate Rights (by the DSA) is done as SYSTEM; > however, the access check is performed with the client authorization context. > > According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller > performs an access check to determine whether the security context, and thus > the requester, is authorized for the type of access that has been requested > before allowing any further processing to continue. > > As you know, access control information associated with an object is > contained in the security descriptor of the object. Therefore, all Validated > Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by > the security descriptor. > > In this particular case, the access check is done against the security > context of the workstation account, which is granted the > RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and > servicePrincipalName attributes of the computer object. > > 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: Bill Wesse > Sent: Thursday, October 29, 2009 9:36 AM > To: 'Andrew Bartlett' > Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter > Wallnöfer' > Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor > (SRX090727600015) > > Good morning Andrew - I am resending this email from October 20. > > Please let me know if this answers your question satisfactorily; if so, I > will consider your question resolved. > > The actual updates for Validate Rights (by the DSA) is done as SYSTEM; > however, the access check is performed with the client authorization context. > > According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller > performs an access check to determine whether the security context, and thus > the requester, is authorized for the type of access that has been requested > before allowing any further processing to continue. > > As you know, access control information associated with an object is > contained in the security descriptor of the object. Therefore, all Validated > Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by > the security descriptor. > > In this particular case, the access check is done against the security > context of the workstation account, which is granted the > RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and > servicePrincipalName attributes of the computer object. > > > 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: Bill Wesse > Sent: Tuesday, October 20, 2009 10:57 AM > To: 'Andrew Bartlett' > Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer > Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor > (SRX090727600015) > > Good morning Andrew - here is the response from our document team. > > Please let me know if this answers your question satisfactorily; if so, I > will consider your question resolved. > > The actual updates for Validate Rights (by the DSA) is done as SYSTEM; > however, the access check is performed with the client authorization context. > > According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller > performs an access check to determine whether the security context, and thus > the requester, is authorized for the type of access that has been requested > before allowing any further processing to continue. > > As you know, access control information associa
[cifs-protocol] Structure of prefixMap over LDAP
MS-ADA3 2.115 describes the prefixmap: Attribute prefixMap The prefixMap attribute is for internal use only. However, it is exposed over LDAP, and I don't see a description of it's format in MS-ADTS. With ldp I see only: 'binary blob'. With ldbsearch, I see: bin/ldbsearch -H ldap://win2k3-2.ad.naomi.abartlet.net -s base -b CN=Schema,CN=Configuration,DC=ad,DC=naomi,DC=abartlet,DC=net -Uadministrator prefixMap # record 1 dn: CN=Schema,CN=Configuration,DC=ad,DC=naomi,DC=abartlet,DC=net prefixMap:: BwAAAFkAAADUEQcAKoZIikEBBcsTCAAqhkiB/xcBBbZuCAAqhkiBzBEBBVBvCAAqhk iCugUBBesFCAAqhkiB8xcBBZQGBwAqhkiJHQEFzwYHACqGSNMFAQU= (and our --show-binary option does not know how to parse this). It was in the past assumed that this attribute was not available over LDAP, but as it is, could you please describe the format? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] salt used for various principal types
On Mon, 2009-10-05 at 10:24 -0700, Sebastian Canevari wrote: > HI Andrew, > > I'm not sure I'm following you. > > The information about the trusts is in section 3.3.5. > > You are stating that the information about the trusts is wrong? Nothing - I didn't realise it was buried at the bottom of the second page. Would it be possible to group all the information in one place? (I was expecting a single complete table of 'account type -> salt algorithm', and was caught out by the unexpected split). Thanks. Andrew Bartett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] salt used for various principal types
On Mon, 2009-09-28 at 12:37 -0700, Sebastian Canevari wrote: > Hi Andrew, > > I have some information to share with you. > > Attached, you will find a PDF with the modified sections detailing the > calculations of the SALT for the various account types. > > Please let me know if this answers your request. Yes, this is exactly what I was after, but seems to be missing the information provided last year about how interdomain trust accounts fit into the problem: > KILE concatenates the following information to use as the > key salt for realm trusts: > >Inbound trusts: realm> | “krbtgt” | > >Outbound trusts: realm> | "krbtgt" | > This worries me, because it implies that either the information is still spread out, or that changes we discuss here are not actually surviving into the docs. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Mon, 2009-09-28 at 13:22 +, Bill Wesse wrote: > Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the > servicePrincipalName constraints (as Hongwei noted). This applies to Windows > 2003/2003 R2, and was fixed in Windows 2008 and beyond. > > This is currently a bug against Windows 2003, but no hotfix has yet been > produced. I will be glad to alert you to when this occurs. > > Here is the response Hongwei provided Thursday, September 10, 2009 8:40 AM: > > We confirmed that Windows server 2008 and later systems addressed the problem > by implementing validation of the DNSHostName and SPN in > NetrLogonGetDomainInfo to enforce the same constraints as specified in > section 3.1.1.5.3.1.1.2(dNSHostName) and > 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. I'm sorry, I must not have been clear in my point: > Did we determine earlier that these updates occur regardless of the access > control on the object (confirmed with AD Dev team, but I don't think it's in > the docs). I refer here to the access control that would normally be imposed by the nTSecurityDescriptor and enforced over LDAP. It is my understanding (discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the actual workstation account), but I don't recall that being in the doc. (This isn't a security hole, because you can only update your own record, but it's important to note for those doing an ACL implementation). Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Wed, 2009-09-02 at 22:09 +, Hongwei Sun wrote: > Andrew, > >We confirmed that Windows server 2008 and later systems addressed the > problem by implementing validation of the DNSHostName and SPN in > NetrLogonGetDomainInfo to enforce the same constraints as specified in > section 3.1.1.5.3.1.1.2(dNSHostName) and > 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. Therefore you should > follow these rules to match the Windows behaviors. > >Please let us know if you have further questions. Did we determine earlier that these updates occur regardless of the access control on the object (confirmed with AD Dev team, but I don't think it's in the docs). Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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] salt used for various principal types
I can't find any reference in either MS-ADTS or MS-KILE regarding the salt used for for the different types of principals in the kerberos protocol. (A salt is used as a confounded in string2key operations in kerberos) I know there are different salt calculations for users and computers, and presumably again for interdomain trust accounts. See: http://lists.samba.org/archive/samba-technical/2004-November/037976.html I asked about this in respect to domain trusts in August 2008, and received an informative reply, but I can't find the algorithm for user/machine accounts written down. Thanks, 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] Bitfields in the WSPP docs
Over a year ago, I wrote to this list about the incredible frustration I suffer on a regular basis attempting to read and use the Microsoft documentation. The problem was regarding the layout and incomprehensible system used to describe the bitfields that occur in so many of the protocol documents I use, and a year on, I was wondering if I had to reinforce my concerns. But there is hope - I've just seen a copy of the MS-CIFS document that Chris Hertel has helped author (contracting to Microsoft), and I'm truly amazed by the progress that has been made. If this document survives intact to final form, it will show that programmer-compatible documentation can be produced within this framework. To pick a random example, I see 2.2.4.43 'SMB_COM_WRITEX_ANDX'. It shows the format of the packet in a clear, text based format, replacing the block diagrams, and the error codes are clearly given both textual names and hexidecimal values. (While it is incredibly disappointing to no longer need to do 2^(n-31) in my head, I do find it a little easier ;-) It also puts to rest the incredibly insane 'bytes in little endian, bits in big endian' that I have to say was so truly 'special'. What I'm trying to say is that I really, really appreciate the improvement. These make the documents the single best example of network interface documentation formatting that I have seen from this protocol program, I strongly hope that whatever challenges have prevented the use of such clear language in other documents might finally have been overcome, so that other critical documents, the RPC documents in particular, can also benefit from this treatment. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Status: CAR - ldap display specifiers (SRX090713600122)
On Thu, 2009-09-10 at 18:51 +, Bill Wesse wrote: > Hello again Andrew - here are the updated display specifier files > (Intellectual Property Rights Notice text commented out, per RFC2849). > > Please let me know if we have satisfied all of your requests; if so, I will > consider the case resolved. I think so. Thanks! Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Status: CAR - ldap display specifiers (SRX090713600122)
On Tue, 2009-09-08 at 22:23 +, Hongwei Sun wrote: > Andrew, > >We just want to check with you to see if the information we provided > answered all of your questions. If you don't have more questions, we will > consider this issue closed. Please let us know. The only feedback we has is: Can you when updating this for us in future ensure you use the exact same format, but prefix the copyright header with # characters, to ensure they are easily recognised as distinct from the LDIF data? We import these files as-is for easy correction, but we had to modify the header manually. See http://gitweb.samba.org/samba.git/?p=samba.git;a=blob;f=source4/setup/display-specifiers/DisplaySpecifiers-Win2k8.txt;h=ab09cc500fd796b1ecf29a4a83ad2fabc99ed306;hb=HEAD for an example Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128)
On Wed, 2009-09-02 at 22:16 +, Hongwei Sun wrote: > Andrew, > >I just want to make sure that you have received all the information for > this request. As Bill already indicated, how the OS version specified in > NETLOGON_WORKSTATION_INFO is translated into the operatingSystemVersion > attribute is documented in 2.2.1.3.16 of MS-NRPC > http://msdn.microsoft.com/en-us/library/dd240432.aspx as follows: > > OsVersionInfo: If not NULL, the attribute operatingSystemVersion on the > client's computer account in Active Directory (using the ABNF Syntax as > specified in [RFC2234]) is set to: > > If OsVersionInfo.dwBuildNumber is 0: > > operatingSystemVersion = MajorVersion "." MinorVersion > MajorVersion = OsVersionInfo.dwMajorVersion > MinorVersion = OsVersionInfo.dwMinorVersionOtherwise: > > operatingSystemVersion = MajorVersion "." MinorVersion > "." > BuildNumber > MajorVersion = OsVersionInfo.dwMajorVersion > MinorVersion = OsVersionInfo.dwMinorVersion > BuildNumber = OsVersionInfo.dwBuildNumber > > >We will add the reference to this information to OsVersion in 2.2.1.3.6 > NETLOGON_WORKSTATION_INFO in the future version of the document. Thankyou. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] erroneous references to little-endian
On Thu, 2009-08-13 at 19:27 +, Hongwei Sun wrote: > Andrew, > > We added the explanation about how bit fields are presented in documents > to MS-DTYP v2.1. This information is consistent with the template we have > been using to write our currently published protocol documents. The updated > section is attached for your review. > > Hopefully this update can provide readers a clear reference when using > bit field tables in the documents. At the same time, we are continuing > working on the broader issue of the bit fields to improve their usability. Well, for me it only confirms the insanity. Can we at least agree to remove the use of bitfield tables where the endian-ness is negotiated (RPC) or otherwise determined (ASN.1)?. The 'network order' bitfeilds make no sense in this situations, as all programming must be done in host-order integers with bitmasks anyway. This remains the single most frustrating part of the documentation because it's clear that Microsoft very much understands the problem, yet is unable to overcome it's insistence on creating this impediment! Thank you in advance for any progress you are able to make in this area, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Status: CAR - ldap display specifiers (SRX090713600122)
On Fri, 2009-08-28 at 07:48 -0700, Bill Wesse wrote: > I will be out of the office on vacation, returning Monday, September 7. My > colleague, Hongwei Sun will be your contact during my absence. Thanks for the heads up. But over a week ago you promised: > Good morning - and thanks for your patience. We are nearly complete with the > property rights notice for the display specifiers ldf. > > I expect to be able to make the final documents available to you within 3-5 > working days! I realise there is little you can do while you wait on lawyers, but I'm worried worried: Will the delay be this long every time we try to clarify the release of this kind of thing? (And we are yet to tell if the final form of the documents will be suitable - legally or technically!). Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Wed, 2009-08-26 at 09:52 -0700, Bill Wesse wrote: > Hello again Andrew - I have a 'short' answer for you. > > Windows 2008 does the following additional checks: > > 1. NETLOGON_WORKSTATION_INFO.DnsHostName and ComputerName match appropriately > (re: trailing '$' on ComputerName) > 2. NETLOGON_WORKSTATION_INFO.DnsHostName suffix is checked against > msDS-AllowedDNSSuffixes. > > I can't at the moment be more complete, without exercising > NetrLogonGetDomainInfo against 2000, 2003 and so on. I hesitate to attempt a > description against code hand-checks, as it is just too easy to miss > something. > > Do you have any test software already configured to do that? You could hack the GetDomainInfo test in smbtorture's RPC-NETLOGON. We don't have anything that lets you set it arbitrarily from the command line (yet, I could write it). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128)
On Tue, 2009-08-25 at 07:17 -0700, Bill Wesse wrote: > Thanks again for your input; my response interpolated below... > > >> Good morning Andrew - I have attached a pdf showing the changes that will > >> be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 > >> NETLOGON_WORKSTATION_INFO OsVersion field description. > >> > >> These changes will reference [MS-RPRN], which has a full definition for > >> the OSVERSIONINFOEX structure; I have provided a link for this: > >> > >> [MS-RPRN]: Print System Remote Protocol Specification > >> 2.2.3.10.2 OSVERSIONINFOEX > >> http://msdn.microsoft.com/en-us/library/cc669279.aspx > >> > >> Please let me know if this answers your question satisfactorily; if so, I > >> will consider the case resolved. Thanks for helping us improve our > >> documentation! > > >While the proposed changes remove the outright incorrect information, I > >don't see how they help us populate the >operatingSystemVersion attribute. > >The references to the update, and the rules by which it is processed need to > >be >corrected rather than just removed. > > I'm not sure I understand what is not specified in '[MS-RPRN] 2.2.3.10.2 > OSVERSIONINFOEX'. After running down the links in that topic, I see they > contain essentially the same information as the MSDN 'OSVERSIONINFOEX > Structure' (link shown below, not included in the doc, since we cannot cite > MSDN content as normative). > > OSVERSIONINFOEX Structure > http://msdn.microsoft.com/en-us/library/ms724833.aspx > > Could you elaborate on what sort of processing you are referring to (beyond > the implicit matching between the OsName text and OsVersion structured data)? No, it is the removal of the explanation of how the OS version specified here is translated into the operatingSystemVersion attribute, and how/when that is done that seems to have been removed. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Tue, 2009-08-25 at 07:04 -0700, Bill Wesse wrote: > Good morning Andrew. Thanks for your feedback. I have interpolated available > information below. > > >> Andrew - I think I might have missed a previous email of yours. If so, I > >> offer my apologies. > >> > >> The actual Windows behavior is - as Matthias noted previously - that > >> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints > >> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4). > > > >OK, When will this security bug be addressed? I thought I saw a difference > >in this behaviour for Windows 2008 - >honestly I was expecting 'Windows 2008 > >fixed this' as your reply. > > This is currently 'work-in-progress', and I will update you as soon as I have > information. My understanding is that this is not an issue with releases > after Windows 2003 (which matches with your comments concerning Windows 2008). Great. Can you give me the exact rules as they apply to Windows 2008 then? I can work from them to fix this up to match Windows 2008 behaviour (which was my original goal, but wasn't what Matthias wrote the code to match). > >> We are currently working on which document this should be addressed in > >> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct > >> place, since SPN validation is carried out by Active Directory, > >> outside the scope of the NetLogon protocol. I do not yet have any > >> information concerning whether or not any product bugs will be filed, > >> but I have alerted the appropriate folks here at Microsoft. That may > >> impact any forthcoming Windows Behavior notes. > > >OK. I would appreciate an update on what the expected long-term behaviour > >of Microsoft products will be, so we >know what we must emulate. (Oh the > >joys of bug-for-bug compatibility) > > Some of this will depend on Windows 2003 and earlier bug/fix details. I will > keep you advised! > > >Thanks for the detail. I look forward to being able to use it some day :-) > > My pleasure! Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Mon, 2009-08-24 at 07:35 -0700, Bill Wesse wrote:
> Andrew - I think I might have missed a previous email of yours. If so, I
> offer my apologies.
>
> The actual Windows behavior is - as Matthias noted previously - that
> NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints
> (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4).
OK, When will this security bug be addressed? I thought I saw a
difference in this behaviour for Windows 2008 - honestly I was expecting
'Windows 2008 fixed this' as your reply.
> We are currently working on which document this should be addressed in
> ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct
> place, since SPN validation is carried out by Active Directory,
> outside the scope of the NetLogon protocol. I do not yet have any
> information concerning whether or not any product bugs will be filed,
> but I have alerted the appropriate folks here at Microsoft. That may
> impact any forthcoming Windows Behavior notes.
OK. I would appreciate an update on what the expected long-term
behaviour of Microsoft products will be, so we know what we must
emulate. (Oh the joys of bug-for-bug compatibility)
> [MS-ADTS]:
> Active Directory Technical Specification
> 3.1.1.5.3.1.1.4 servicePrincipalName
> The object has class computer (or a subclass of computer).
> In AD DS, the servicePrincipalName value satisfies the following
> constraints:
> o The SPN is a syntactically correct two-part SPN (see section 5.1.1.4,
> "Mutual Authentication").
> o The instance name matches one of the following: the full DNS name of
> the machine, the sAMAccountName of the machine (without the terminating "$"),
> one of the msDS-AdditionalDnsHostName, or one of the
> msDS-AdditionalSamAccountName (without the terminating "$").
>
> The guidance I provided earlier addresses these constraints; I regret
> omitting the reference to [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName.
>
> > Before updating the servicePrincipalName attribute ("HOST/dNSHostName") for
> > the account under the established secure channel, the following checks
> > would be prudent:
> >
> >Reference:
> >[MS-ADA3]: Active Directory Schema Attributes N-Z
> >2.252 Attribute servicePrincipalName
> >
> > 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine)
> > account sAMAccountName attribute (minus the trailing '$' character) for the
> > account under the established secure channel.
> >
> >Reference:
> >[MS-ADA3]: Active Directory Schema Attributes N-Z
> >2.221 Attribute sAMAccountName
> >
> > 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine)
> > account dNSHostName attribute for the account under the established secure
> > channel.
> >
> >Reference:
> >[MS-ADA1]: Active Directory Schema Attributes A-L
> >2.185 Attribute dNSHostName
> >
> > 3. NETLOGON_WORKSTATION_INFO.DnsHostName must have an allowed DNS suffix
> > (e.g., the domain DNS name).
> >
> >Reference:
> >[MS-ADA2]: Active Directory Schema Attributes M
> >2.181 Attribute msDS-AllowedDNSSuffixes
Thanks for the detail. I look forward to being able to use it some
day :-)
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco 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
Re: [cifs-protocol] Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128)
On Mon, 2009-08-24 at 07:41 -0700, Bill Wesse wrote: > Good morning Andrew - I have attached a pdf showing the changes that will be > in the next update to [MS-NRPC] concerning section 2.2.1.3.6 > NETLOGON_WORKSTATION_INFO OsVersion field description. > > These changes will reference [MS-RPRN], which has a full definition for the > OSVERSIONINFOEX structure; I have provided a link for this: > > [MS-RPRN]: Print System Remote Protocol Specification > 2.2.3.10.2 OSVERSIONINFOEX > http://msdn.microsoft.com/en-us/library/cc669279.aspx > > Please let me know if this answers your question satisfactorily; if so, I > will consider the case resolved. Thanks for helping us improve our > documentation! While the proposed changes remove the outright incorrect information, I don't see how they help us populate the operatingSystemVersion attribute. The references to the update, and the rules by which it is processed need to be corrected rather than just removed. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Mon, 2009-08-10 at 17:42 +1000, Andrew Bartlett wrote: > On Fri, 2009-07-31 at 07:31 -0700, Bill Wesse wrote: > > Thank you for the information on how R2 handles this. I will dig into that > > starting later today. > > Has there been any progress clarifying the actual windows behaviour in > the past 10 days? > > We would like to move on with a solution that both matches the > documentation and the demonstrated behaviour soon. I would really like to get this clarified for the next Samba4 alpha. I'm not too happy with the client being able to set any value, but this appears to be the windows behaviour. Will there be any clarification forthcoming? Thanks, -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] How to determine if an account should use AES?
On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote: > Hi Andrew, > > The msDS-SupportedEncryptionTypes attribute is populated at object creation > time by the subjects that support the property. So it is modified over LDAP by the Windows Vista (for example) domain member? > It is also updated whenever there's a change on the object's > configuration that require an update of the property. So if the domain member upgrades, it is expected to reach out and update this property using LDAP? Are there any ACL considerations to be aware of here? Are there any other restrictions on the values clients might populate here? > Meaning that when a subject changes the type of encryption it > supports, it modifies this attribute to reflect the change. Any chance you can provide an annotated (ie, with a separate document mentioning frame numbers) PCAP-formatted example network trace and documentation references to support this? I would really like to pin this down firmly before the next alpha, now that I've turned on the Windows 2008 functional level and therefore AES encryption in our DC. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] How to determine if an account should use AES?
On Fri, 2009-08-14 at 11:40 -0700, Sebastian Canevari wrote: > Hi Andrew, > > I've been investigating this and I'm still discussing with the product group > what would be the best way to better detail this process. > > As explained in the document, the KDC will rely on the AD property > msDS-SupportedEncryptionTypes. > Now, if the property is not populated by the server or service, then the KDC > will default to RC4 which is the legacy type. So, the outstanding question is: what would normally populate that attribute? > With respect to the NETLOGON_DOMAIN_INFO, Matthieu is working with Obaid on > that section and I believe Obaid is sending him his response shortly. I have to say, I'm not the wiser from Obaid's answer. Sorry. Perhaps you could spell it out a bit more clearly? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Fri, 2009-07-31 at 07:31 -0700, Bill Wesse wrote: > Thank you for the information on how R2 handles this. I will dig into that > starting later today. Has there been any progress clarifying the actual windows behaviour in the past 10 days? We would like to move on with a solution that both matches the documentation and the demonstrated behaviour soon. Thanks, -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco 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
