date:20100201

Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP

2010-02-01 Thread Bill Wesse

Good morning again. Sebastian will be back in the office today; I have 
transferred case ownership back to him.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Bill Wesse 
Sent: Thursday, January 28, 2010 11:46 AM
To: 'abart...@samba.org'; 'kamen.mazdras...@postpath.com'
Cc: Sebastian Canevari; Obaid Farooqi; 'p...@tridgell.net'; 
'cifs-proto...@samba.org'
Subject: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of prefixMap over 
LDAP

Good day Andrew & Kamen. Please note that my colleague Sebastian (who took 
ownership of this case from Obaid) is out of the office for the next few days.

In the interim, I will be your contact. Thanks in advance for your patience!

Andrew - I sent a status update request for the TDI (which has been in suspense 
since one of your previous emails (shown at the end of this message). I will 
advise you as soon as I receive a response.

Kamen - I have already performed some investigation concerning those 20 other 
prefixMap entries, and expect to follow up with your tomorrow morning. 

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com]
Sent: Friday, January 15, 2010 3:09 AM
To: Obaid Farooqi; abart...@samba.org
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP

Hi Obaid,

Could you please point out where those default 39 entries for prefixMap are 
described?
I am looking at: 

and there are only 19 default prefixes listed here.

Thanks,
Kamen Mazdrashki
kamen.mazdras...@postpath.com 

-
CISCO SYSTEMS BULGARIA EOOD

-Original Message-
From: Andrew Bartlett [mailto:abart...@samba.org] 
Sent: Tuesday, December 15, 2009 1:39 AM
To: Obaid Farooqi
Cc: cifs-proto...@samba.org; p...@tridgell.net
Subject: RE: 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.

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

Re: [cifs-protocol] Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL entries

2010-02-01 Thread Bill Wesse

Good morning again. Sebastian will be back in the office today; I have just 
reassigned this case back to him.

Sebastian - Matthieu has replied to my email from last Thursday with ACL/SDDL 
considerations that look to be a new case. I was unfortunately taken ill last 
Friday, and was not able to respond.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] 
Sent: Friday, January 29, 2010 6:05 PM
To: Bill Wesse
Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@tridgell.net
Subject: Re: Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL 
entries

On 28/01/2010 19:54, Bill Wesse wrote:
> Good day Matthieu. Please note that my colleague Sebastian is out of the 
> office for the next few days. In the interim, I will be your contact. Thanks 
> in advance for your patience!
>
> I have reviewed the case, and want to make sure I address any open questions. 
> My current read indicates we haven't answered the below question. Could you 
> confirm this is the case, and advise me of any other open questions you have?
>
> And last but not least question, it seems that GPMC wants to have OI and CI 
> flags on every ACL entries; is it due to the presence of the 
> "SDDL_AUTO_INHERITED">control in the SDDL?
>
Well I'm not sure of this because I remember an email from Hongwei that 
told me that they were set because it was coded like that ...

But in fact I would like to come back to you about NT ACLs (but maybe it 
might be filled in another case let me know if you want to do so).
Lately I discovered that subinacl is able du dump NT ACLs in SDDL format.
I checked and it seems that the dump is ok (at least the owner is ok, 
the different granted users/groups are ok also).
So for instance a w2k3 server acting as a DC I have :
  c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
0C04fB984F9}
/sddl=O:BAG:SYD:PARAI(A;;0x1200a9;;;AU)(A;OICIIO;GXGR;;;AU)(A;;0x1200a9;;;SO)(A;
OICIIO;GXGR;;;SO)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;
;FA;;;BA)(A;OICIIO;GA;;;CO)

It was obtained from:
subinacl.exe /file  
c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
0C04fB984F9} /display=sddl

But if dump the ACL of the object

CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=Samba,DC=net

O:DAG:DAD:PAI(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;EA)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;RPLCLORC;;;ED)S:AI(OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-f80367c1;WD)(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

So even if we remove the SACL and apply the transformation rules 
proposed before there is a huge difference between the file DS ACL and 
the associated file ACL (owner/group is different, BA is used in file 
ACL when DA is used in DS ACL). So it is seems that the logic is not ok 
(although it makes gpmc happy).

Can you explain this ? Can you take from your side dump of a fresh 
w2k3r2 dc (or w2k8/w2k8r2) and look for the ACL on files/dir associated 
with GPO and with the GPO objects as well ?

Regards.
Matthieu.

> Thanks in advance!
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
>
> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net]
> Sent: Tuesday, December 22, 2009 3:56 PM
> To: Hongwei Sun
> Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@tridgell.net
> Subject: Re: FW: [cifs-protocol] Group Policy questions
>
> On 23/12/2009 00:47, Hongwei Sun wrote:
>
>> Matthieu,
>>
>>  Your summary is a good recap of what we have done on this topic.   I 
>> have one clarification for the point below.
>>
>>   * All ACE for allowed object are wipped out when
>> "translating" AD ACL to File ACL
>>
>>  When translating a ACL for DS object to a ACL for SYSVOL file 
>> object,  the ACEs with types of  ACCESS_ALLOWED_OBJECT_ACE_TYPE, 
>> ACCESS_DENIED_OBJECT_ACE_TYPE and SYSTEM_AUDIT_OBJECT_ACE_TYPE are not 
>> really deleted from the ACL.  Instead, for such a ACE, access mask in 
>> AceHeader is assigned to zero.
>>
>>  
> Yeah I meant that when "translating" an AD ACL to a file ACL we do not care 
> about it, for all those ACCESS_ALLOWED_OBJECT_ACE_TYPE in the AD no 
> corresponding ACE in created.
>
>
>
>>  Sebastian wil

Re: [cifs-protocol] Status: SRX100106600091 [MS-ADTS]: RID manage behavior

2010-02-01 Thread Bill Wesse

Good morning Andrew. Sebastian will be back in the office today. I have just 
reassigned the case back to him.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Bill Wesse 
Sent: Friday, January 29, 2010 6:18 AM
To: 'abart...@samba.org'
Cc: Sebastian Canevari; 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 
'tri...@samba.org'
Subject: RE: Status: SRX100106600091 [MS-ADTS]: RID manage behavior

Good evening Andrew! Document work is still in progress, but we would like to 
provide the following workaround/information for you:

Beyond the Knowledge Base article previously given (Description of RID 
Attributes in Active Directory: http://support.microsoft.com/kb/305475), which 
gives some description of the attributes in question, the following may be 
useful in providing more info on RID allocation:

o   A general description of the RID Master Role is given in [MS-ADTS] 
Section 7.1.5.2

o   Role transfer is handled via RootDSE mods given in [MS-ADTS] section 
3.1.1.3.3 or the RPC in [MS-DRSR] section 4.1.10.4.3.

o   The RID Master is responsible for maintaining rIDAvailablePool and 
rIDAllocationPool.  It assigns rIDAllocationPool values for DCs via the RPC 
described in [MS-DRSR] section 4.1.10.5.12 (Specifically in the case where 
msgIn.ulExtendedOp = EXOP_FSMO_REQ_RID_ALLOC)

o   New RIDs are used/assigned by a DC when creating new SIDs following the 
process documented in [MS-SAMR] section 3.1.1.9.2.  This process is the same 
regardless of whether the DC creating the new object is the RID Master or not; 
if the DC creating the new object is the RID Master and it requires a new 
rIDAllocationPool, it may invoke the previously mentioned RPC against itself.

Regarding the ridNextRID and ridPreviousAllocationPool attributes, these are 
non-replicated attributes used only by the DC storing them when allocating RIDs.

o   ridNextRID tracks the most recently assigned RID.  When assigning a new 
RID, the DC adds 1 to this and validates that it is within the proper bounds.  
This is used to guarantee that no RID is used twice per the requirement in 
[MS-SAMR] section 3.1.1.9.2.1.

o   ridPreviousAllocationPool is actually the current pool from which the 
DC is assigning RIDs.  It provides the bounds that ridNextRID is checked 
against when assigning new RIDs.  It serves as a cache for the rid pools and 
must always be set to a rIDAllocationPool previously received by the RID 
Master.  (It may match the current value of rIDAllocationPool for the given DC 
or a previous value of it.)

While any implementation that follows the rules for RID allocation given in 
[MS-SAMR] section 3.1.1.9.2.1 should result in a compatible DC, the use of 
ridPreviousAllocationPool by Microsoft DCs means that they may allocate RIDs 
outside the current range given by rIDAllocationPool, though such RIDs will 
still be within a range it previously held.  We will work on the TD to address 
this.

If there is anything else in the meantime that you need to unblock your work on 
RID allocation, please let us know.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Bill Wesse 
Sent: Thursday, January 28, 2010 12:04 PM
To: 'abart...@samba.org'
Cc: Sebastian Canevari; 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 
'tri...@samba.org'
Subject: Status: SRX100106600091 [MS-ADTS]: RID manage behavior

Good day Andrew! Please note that my colleague Sebastian is out of the office 
for the next few days. In the interim, I will be your contact. Thanks in 
advance for your patience!

We submitted a Technical Document Inquiry (TDI) ~2 weeks ago, on Jan 14. I just 
sent a status update request for the TDI, and will advise you as soon as I 
receive a response.

Thanks for your patience!

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Andrew Bartlett [mailto:abart...@samba.org] 
Sent: Tuesday, January 12, 2010 4:37 PM
To: Sebastian Canevari
Subject: RE: RID Allocation behaviour

On Tue, 2010-01-12 at 18:22 +, Sebastian Canevari wrote:
> Hi Andrew,
> 
> Can you please let me know if this response answers your question or if you 
> need further clarification?

Well, firstly, the answer needs to be in the WSPP documentation set.  

Secondly I don't think it answers the particular points I asked about - it 
describes the attributes (good) but not the behaviour and responsibilities.  

Some of this

Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP

2010-02-01 Thread Kamen Mazdrashki

Thanks Bill,

Btw, we've implemented prefixMap over ldap dump handler and it works great.
Many thanks for publishing the format.

BR,
Kamen Mazdrashki
kamen.mazdras...@postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

> -Original Message-
> From: Bill Wesse [mailto:bil...@microsoft.com]
> Sent: Monday, February 01, 2010 3:14 PM
> To: abart...@samba.org; Kamen Mazdrashki
> Cc: Sebastian Canevari; Obaid Farooqi; p...@tridgell.net; cifs-
> proto...@samba.org
> Subject: RE: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of
> prefixMap over LDAP
> 
> Good morning again. Sebastian will be back in the office today; I have
> transferred case ownership back to him.
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
> 
> 
> -Original Message-
> From: Bill Wesse
> Sent: Thursday, January 28, 2010 11:46 AM
> To: 'abart...@samba.org'; 'kamen.mazdras...@postpath.com'
> Cc: Sebastian Canevari; Obaid Farooqi; 'p...@tridgell.net'; 'cifs-
> proto...@samba.org'
> Subject: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of
> prefixMap over LDAP
> 
> Good day Andrew & Kamen. Please note that my colleague Sebastian (who
> took ownership of this case from Obaid) is out of the office for the
> next few days.
> 
> In the interim, I will be your contact. Thanks in advance for your
> patience!
> 
> Andrew - I sent a status update request for the TDI (which has been in
> suspense since one of your previous emails (shown at the end of this
> message). I will advise you as soon as I receive a response.
> 
> Kamen - I have already performed some investigation concerning those 20
> other prefixMap entries, and expect to follow up with your tomorrow
> morning.
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
> 
> -Original Message-
> From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com]
> Sent: Friday, January 15, 2010 3:09 AM
> To: Obaid Farooqi; abart...@samba.org
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP
> 
> Hi Obaid,
> 
> Could you please point out where those default 39 entries for prefixMap
> are described?
> I am looking at:  us/library/cc228445%28PROT.13%29.aspx>
> and there are only 19 default prefixes listed here.
> 
> 
> 
> Thanks,
> Kamen Mazdrashki
> kamen.mazdras...@postpath.com 
> 
> -
> CISCO SYSTEMS BULGARIA EOOD
> 
> 
> -Original Message-
> From: Andrew Bartlett [mailto:abart...@samba.org]
> Sent: Tuesday, December 15, 2009 1:39 AM
> To: Obaid Farooqi
> Cc: cifs-proto...@samba.org; p...@tridgell.net
> Subject: RE: 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 Bartlett
> http://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] Bug in MS-WINSRA section "2.2.10.1 Name Record"

2010-02-01 Thread Edgar Olougouna

Hi Stefan,

I am taking care of this case and will update you as soon as I have news.

Best regards,

Edgar



-Original Message-
From: Bill Wesse 
Sent: Saturday, January 30, 2010 7:37 AM
To: Stefan (metze) Metzmacher
Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna
Subject: [REG:110012953632586] RE: Bug in MS-WINSRA section "2.2.10.1 Name 
Record"

Thanks Stefan - forwarding this email to Edgar, who owns the case.

110012953632586

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Stefan (metze) Metzmacher [mailto:me...@samba.org] 
Sent: Saturday, January 30, 2010 4:40 AM
To: Bill Wesse
Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation 
Help
Subject: Re: Bug in MS-WINSRA section "2.2.10.1 Name Record"

Hi Bill,

there's one additional bug regarding the Name length.

>
> Name (variable): Name terminates with a 0x00 byte. It may include a 
> NetBIOS scope identifier, as specified in [RFC1001]. The maximum 
> length of the Name field is 255 bytes including the 0x00 byte. If no 
> NetBIOS scope is included, then the length of the name is 17 including 
> the 0x00 byte.

When a windows server gets a name with length == 255 it removes the last 
character of the scope before storing it.

Windows returns a name with length 254 when it returns the name again.

See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a 
modified smbtorture).

Frame 19 smbtorture => windows 2008 name length 255 Frame 25 windows 2008 => 
smbtorture name length 254

metze
> Good morning Stefan - I am including our below initial response, since I 
> missed CC: doch...@microsoft.com on the first one.
> 
> -Original Message-
> From: Bill Wesse
> Sent: Friday, January 29, 2010 9:59 AM
> To: 'me...@samba.org'
> Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org'
> Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record 
> Padding field description incorrect
> 
> Good morning Stefan - thanks for your comments. I have created the below case 
> to track the issue. One of my team members will contact you shortly!
> 
> 110012953632586 [MS-WINSRA] 2.2.10.1 Name Record Padding field 
> description incorrect
> 
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
> 
> 
> -Original Message-
> From: Stefan (metze) Metzmacher [mailto:me...@samba.org]
> Sent: Friday, January 29, 2010 9:25 AM
> To: Interoperability Documentation Help
> Cc: p...@tridgell.net; cifs-proto...@samba.org
> Subject: CAR: Bug in MS-WINSRA section "2.2.10.1 Name Record"
> 
> Hi,
> 
> I found a bug in MS-WINSRA section "2.2.10.1 Name Record".
> 
> It says:
> 
>> Padding (variable): If the Name field is not 4-byte aligned, this 
>> Padding field will be added to pad to 4-byte alignment. If the Name 
>> field itself is 4-byte aligned, then there is no Padding field. This 
>> field MUST be ignored upon receipt.
> 
> This is wrong!
> 
> The documentation would indicate this:
> 
> pad_len = ((offset & (4-1)) == 0 ? 0 : (4 - (offset & (4-1
> 
> But Windows Servers (at least 2003 SP1 and 2008) use this:
> 
> pad_len = 4 - (offset & (4-1));
> 
> The difference is the case where the name field is already 4 byte aligned. In 
> that case Windows adds 4 bytes instead of 0 bytes of aligment.
> 
> See frame 75 in the attached capture (172.31.9.211 is a windows 2008 server 
> and 172.31.9.1 a modified smbtorture).
> The name length is 20 and there're 4 extra bytes before the Reserved1 field.

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

Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute

2010-02-01 Thread Hongwei Sun

Tridge,

  Could you please take a look at my question below so I can proceed with this 
request ?   If you are busy,  we can always come back to visit it whenever it 
is good time for you.

Thanks !

Hongwei 

-Original Message-
From: Hongwei Sun 
Sent: Tuesday, January 19, 2010 9:31 PM
To: 'tri...@samba.org'
Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder; MSSolve Case 
Email
Subject: [REG:110011477385004] RE: userParameters attribute

Tridge,

   How did you generate the UserParameters you mentioned in the e-mail ?  I got 
a little bit different result.   The steps  I used are

(1) Open "Avtive Directory Users and Computers" ->  "User"  ->  select a user 
such as "Administrator"
(2) In Properties windows , select "Sessions" tab and then change "Active 
session limit" 
(3) Then the UserParametes attribute was added to the user object,  the value 
is something like 
 userParameters:   
PCtxCfgPresentCtxCfgFlags1CtxShadow*CtxMinEncryptionLevel?"
 

  UserParameters attribute is used for storing user specific data for 
individual programs, such as RAS and Terminal Service.  I just want to make 
sure we are looking at the same tool. 

Thanks!

Hongwei

-Original Message-
From: tri...@samba.org [mailto:tri...@samba.org] 
Sent: Thursday, January 14, 2010 2:55 PM
To: Interoperability Documentation Help
Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder
Subject: CAR: userParameters attribute

Dear Dochelp,

The userParameters attribute on a user in AD seems to be a bit of a
puzzle. Could you add some docs on it at some stage? Not a really high
priority, but we would eventually like to be able to offer admin tools
that manage things like session activity timeouts, and it seems that
we need to know how to parse and create userParameters to do that.

An example userParameters attribute from w2k8r2 (in base64 form) is this:

userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI
  CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU
  N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C
  w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0
  aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya
  0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm
  Ft44Cw

the above came from using the windows user admin tool to change the
session activity timeout for a test user.

Michael Ströder has also pointed out this page:

  http://daduke.org/linux/userparameters.html

which documents a previous effort by the Linux thin client community
to work out the format of userParameters. I'm guessing the strange
encoding is used to try to keep the attribute as valid UTF8. If you
can confirm that the attribute is always valid UTF8 that would be
great (as otherwise we might corrupt it during replication with
windows).

As I mentioned, this is not a high priority, but it would be nice to
know the format at some stage.

Cheers, Tridge

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

Re: [cifs-protocol] Status: SRX100106600091 [MS-ADTS]: RID manage behavior

2010-02-01 Thread Sebastian Canevari

Hi Andrew,

Please let me know if you need any further clarification regarding this 
information.

Thanks and regards,

Sebastian

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: seba...@microsoft.com

-Original Message-
From: Bill Wesse 
Sent: Friday, January 29, 2010 6:18 AM
To: 'abart...@samba.org'
Cc: Sebastian Canevari; 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 
'tri...@samba.org'
Subject: RE: Status: SRX100106600091 [MS-ADTS]: RID manage behavior

Good evening Andrew! Document work is still in progress, but we would like to 
provide the following workaround/information for you:

Beyond the Knowledge Base article previously given (Description of RID 
Attributes in Active Directory: http://support.microsoft.com/kb/305475), which 
gives some description of the attributes in question, the following may be 
useful in providing more info on RID allocation:

o   A general description of the RID Master Role is given in [MS-ADTS] 
Section 7.1.5.2

o   Role transfer is handled via RootDSE mods given in [MS-ADTS] section 
3.1.1.3.3 or the RPC in [MS-DRSR] section 4.1.10.4.3.

o   The RID Master is responsible for maintaining rIDAvailablePool and 
rIDAllocationPool.  It assigns rIDAllocationPool values for DCs via the RPC 
described in [MS-DRSR] section 4.1.10.5.12 (Specifically in the case where 
msgIn.ulExtendedOp = EXOP_FSMO_REQ_RID_ALLOC)

o   New RIDs are used/assigned by a DC when creating new SIDs following the 
process documented in [MS-SAMR] section 3.1.1.9.2.  This process is the same 
regardless of whether the DC creating the new object is the RID Master or not; 
if the DC creating the new object is the RID Master and it requires a new 
rIDAllocationPool, it may invoke the previously mentioned RPC against itself.

Regarding the ridNextRID and ridPreviousAllocationPool attributes, these are 
non-replicated attributes used only by the DC storing them when allocating RIDs.

o   ridNextRID tracks the most recently assigned RID.  When assigning a new 
RID, the DC adds 1 to this and validates that it is within the proper bounds.  
This is used to guarantee that no RID is used twice per the requirement in 
[MS-SAMR] section 3.1.1.9.2.1.

o   ridPreviousAllocationPool is actually the current pool from which the 
DC is assigning RIDs.  It provides the bounds that ridNextRID is checked 
against when assigning new RIDs.  It serves as a cache for the rid pools and 
must always be set to a rIDAllocationPool previously received by the RID 
Master.  (It may match the current value of rIDAllocationPool for the given DC 
or a previous value of it.)

While any implementation that follows the rules for RID allocation given in 
[MS-SAMR] section 3.1.1.9.2.1 should result in a compatible DC, the use of 
ridPreviousAllocationPool by Microsoft DCs means that they may allocate RIDs 
outside the current range given by rIDAllocationPool, though such RIDs will 
still be within a range it previously held.  We will work on the TD to address 
this.

If there is anything else in the meantime that you need to unblock your work on 
RID allocation, please let us know.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Bill Wesse 
Sent: Thursday, January 28, 2010 12:04 PM
To: 'abart...@samba.org'
Cc: Sebastian Canevari; 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 
'tri...@samba.org'
Subject: Status: SRX100106600091 [MS-ADTS]: RID manage behavior

Good day Andrew! Please note that my colleague Sebastian is out of the office 
for the next few days. In the interim, I will be your contact. Thanks in 
advance for your patience!

We submitted a Technical Document Inquiry (TDI) ~2 weeks ago, on Jan 14. I just 
sent a status update request for the TDI, and will advise you as soon as I 
receive a response.

Thanks for your patience!

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Andrew Bartlett [mailto:abart...@samba.org] 
Sent: Tuesday, January 12, 2010 4:37 PM
To: Sebastian Canevari
Subject: RE: RID Allocation behaviour

On Tue, 2010-01-12 at 18:22 +, Sebastian Canevari wrote:
> Hi Andrew,
> 
> Can you please let me know if this response answers your question or if you 
> need further clarification?

Well, firstly, the answer needs to be in the WSPP documentation set.  

Secondly I don't think it answers the particular points I asked about - it 
describes the attributes (good) but not the behaviour and responsibilities.  

Some of this is implied by an attri

[cifs-protocol] [REG:110011477385004] RE: userParameters attribute

2010-02-01 Thread tridge

Hi Hongwei,

 >How did you generate the UserParameters you mentioned in the
 >   e-mail ?

The process I used was similar to what you describe. I imagine the
exact values of userParameters depends on what values you choose in
the Sessions tab.

 >   UserParameters attribute is used for storing user specific data
 >   for individual programs, such as RAS and Terminal Service.  I
 >   just want to make sure we are looking at the same tool.

yes, I think we're looking at the same tool. What we're hoping to find
out is how to parse the userParameters attribute correctly, both so we
can display the contents and so we can create it in our own user
management tools. Those tools don't exist yet, which is why this
request is a lower priority than other requests :-)

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

Re: [cifs-protocol] Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL entries

2010-02-01 Thread Sebastian Canevari

Hi Matthieu,

I am still working with the product group on documenting what we have been 
working on (the way GPMC checks and corrects the ACLs).

It's become a little bit more complicated than anticipated but I will keep you 
updated of the progress as soon as I have news.

On the other hand, I have just created a case with your new set of 
observations/questions and someone from my team will contact you shortly to 
follow up about this new case.

Thanks and regards,

Sebastian

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: seba...@microsoft.com

-Original Message-
From: Bill Wesse 
Sent: Monday, February 01, 2010 7:20 AM
To: Matthieu Patou
Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@tridgell.net
Subject: RE: Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL 
entries

Good morning again. Sebastian will be back in the office today; I have just 
reassigned this case back to him.

Sebastian - Matthieu has replied to my email from last Thursday with ACL/SDDL 
considerations that look to be a new case. I was unfortunately taken ill last 
Friday, and was not able to respond.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:  bil...@microsoft.com
Tel:+1(980) 776-8200
Cell:   +1(704) 661-5438
Fax:+1(704) 665-9606

-Original Message-
From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net]
Sent: Friday, January 29, 2010 6:05 PM
To: Bill Wesse
Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@tridgell.net
Subject: Re: Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL 
entries

On 28/01/2010 19:54, Bill Wesse wrote:
> Good day Matthieu. Please note that my colleague Sebastian is out of the 
> office for the next few days. In the interim, I will be your contact. Thanks 
> in advance for your patience!
>
> I have reviewed the case, and want to make sure I address any open questions. 
> My current read indicates we haven't answered the below question. Could you 
> confirm this is the case, and advise me of any other open questions you have?
>
> And last but not least question, it seems that GPMC wants to have OI and CI 
> flags on every ACL entries; is it due to the presence of the 
> "SDDL_AUTO_INHERITED">control in the SDDL?
>
Well I'm not sure of this because I remember an email from Hongwei that told me 
that they were set because it was coded like that ...

But in fact I would like to come back to you about NT ACLs (but maybe it might 
be filled in another case let me know if you want to do so).
Lately I discovered that subinacl is able du dump NT ACLs in SDDL format.
I checked and it seems that the dump is ok (at least the owner is ok, the 
different granted users/groups are ok also).
So for instance a w2k3 server acting as a DC I have :
  c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
0C04fB984F9}
/sddl=O:BAG:SYD:PARAI(A;;0x1200a9;;;AU)(A;OICIIO;GXGR;;;AU)(A;;0x1200a9;;;SO)(A;
OICIIO;GXGR;;;SO)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;
;FA;;;BA)(A;OICIIO;GA;;;CO)

It was obtained from:
subinacl.exe /file
c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
0C04fB984F9} /display=sddl

But if dump the ACL of the object

CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=Samba,DC=net

O:DAG:DAD:PAI(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;EA)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;RPLCLORC;;;ED)S:AI(OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-f80367c1;WD)(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

So even if we remove the SACL and apply the transformation rules proposed 
before there is a huge difference between the file DS ACL and the associated 
file ACL (owner/group is different, BA is used in file ACL when DA is used in 
DS ACL). So it is seems that the logic is not ok (although it makes gpmc happy).

Can you explain this ? Can you take from your side dump of a fresh
w2k3r2 dc (or w2k8/w2k8r2) and look for the ACL on files/dir associated with 
GPO and with the GPO objects as well ?

Regards.
Matthieu.

> Thanks in advance!
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:bil...@microsoft.com
> Tel:  +1(980) 776-8200
> Cell: +1(704) 661-5438
> Fax:  +1(704) 665-9606
>
> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net]
> Sent: Tuesday, December 22, 2009 3:56 PM
> To: Hongwei Sun
> Cc: Sebastian Canevari; cifs-proto...@samba

Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490

2010-02-01 Thread Hongwei Sun

Andrew,

  I just want to check with you to see if you have any questions regarding the 
request and our response below.  If not,  I will resolve this case for now.

Thanks!

Hongwei 

-Original Message-
From: Hongwei Sun 
Sent: Monday, January 18, 2010 6:27 PM
To: 'Andrew Bartlett'
Cc: p...@tridgell.net; cifs-proto...@samba.org; Andrew Tridgell
Subject: RE: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text 
files SRX090109601490

Andrew & Tridge,

   I finished reviewing the changes you made to the schema file in order to 
join Windows 2008R2 to Samba domain.   For the attributes affected,  from my 
initial review of MS-ADA*/MS-ADSC and code, they will probably result in many 
change requests to schema documentation.  We will make sure that any correction 
you made will be properly reflected in the documentation after confirmation 
from the product team.   We really appreciate the information you passed back 
to us, which is really valuable for us to improve schema documentation.  

   Looking back at the history of the request , the previous delivery of a 
single  schema text file  combined from the AD* documents is not intended as a 
permanent process of releasing and maintaining schemas in separate documents, 
rather a temporary solution to provide a good starting point to unblock your 
development.   But we did request the product team to evaluate the possibility  
for them to create and maintain the separate schema files.   We will let you 
know when there is any update on this.   By the way,  there is an entry in our 
team blog site for how to relate schema to AD documentations 
(http://blogs.msdn.com/openspecification/archive/2009/06/26/using-the-windows-server-protocols-documentation-set-to-better-understand-the-active-directory-schema.aspx).

Thanks!

Hongwei

-Original Message-
From: Andrew Bartlett [mailto:abart...@samba.org] 
Sent: Monday, January 11, 2010 2:42 PM
To: Hongwei Sun
Cc: p...@tridgell.net; cifs-proto...@samba.org; Andrew Tridgell
Subject: 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.

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

Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP

Re: [cifs-protocol] Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL entries

Re: [cifs-protocol] Status: SRX100106600091 [MS-ADTS]: RID manage behavior

Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP

Re: [cifs-protocol] Bug in MS-WINSRA section "2.2.10.1 Name Record"

Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute

Re: [cifs-protocol] Status: SRX100106600091 [MS-ADTS]: RID manage behavior

[cifs-protocol] [REG:110011477385004] RE: userParameters attribute

Re: [cifs-protocol] Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL entries

Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490

10 matches

Site Navigation

Mail list logo

Footer information