forked from OVALProject/Sandbox
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathx-win-ntuser.xsd
423 lines (423 loc) · 39.4 KB
/
x-win-ntuser.xsd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" xmlns:oval-def="http://oval.mitre.org/XMLSchema/oval-definitions-5"
xmlns:oval-sc="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5" xmlns:win-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"
xmlns:win-sc="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows" xmlns:x-win-ntuser="http://oval.mitre.org/XMLSchema/x-win-ntuser"
xmlns:sch="http://purl.oclc.org/dsdl/schematron" targetNamespace="http://oval.mitre.org/XMLSchema/x-win-ntuser" elementFormDefault="qualified" version="5.11">
<xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-definitions-5" schemaLocation="oval-definitions-schema.xsd"/>
<xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5" schemaLocation="oval-system-characteristics-schema.xsd"/>
<xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" schemaLocation="windows-definitions-schema.xsd"/>
<xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows" schemaLocation="windows-system-characteristics-schema.xsd"/>
<xsd:annotation>
<xsd:documentation>The following is a proposal for the experimental win-def:ntuser_test and win-sc:ntuser_item that will support checking the ntuser.dat file for all users on a Windows
system.</xsd:documentation>
<xsd:appinfo>
<schema>Experimental Schema for the Windows NTUser Test</schema>
<version>5.11</version>
<date>4/23/2013 8:00:00 AM</date>
<terms_of_use>Copyright (c) 2002-2012, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at
http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing
copies of the OVAL Schema, this license header must be included.</terms_of_use>
<sch:ns prefix="oval-def" uri="http://oval.mitre.org/XMLSchema/oval-definitions-5"/>
<sch:ns prefix="oval-sc" uri="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5"/>
<sch:ns prefix="win-def" uri="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"/>
<sch:ns prefix="win-sc" uri="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows"/>
<sch:ns prefix="x-win-ntuser" uri="http://oval.mitre.org/XMLSchema/x-win-ntuser"/>
<sch:ns prefix="xsi" uri="http://www.w3.org/2001/XMLSchema-instance"/>
</xsd:appinfo>
</xsd:annotation>
<!-- =============================================================================== -->
<!-- =============================== NTUSER TEST =============================== -->
<!-- =============================================================================== -->
<xsd:element name="ntuser_test" substitutionGroup="oval-def:test">
<xsd:annotation>
<xsd:documentation>The ntuser test is used to check metadata associated with Windows ntuser.dat files. It extends the standard TestType as defined in the oval-definitions-schema and
one should refer to the TestType description for more information. The required object element references a ntuser_object and the optional state element specifies the ntuser
data to check.</xsd:documentation>
<xsd:appinfo>
<oval:element_mapping>
<oval:test>ntuser_test</oval:test>
<oval:object>ntuser_object</oval:object>
<oval:state>ntuser_state</oval:state>
<oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows">ntuser_item</oval:item>
</oval:element_mapping>
</xsd:appinfo>
<xsd:appinfo>
<sch:pattern id="win-def_ntusertst">
<sch:rule context="win-def:ntuser_test/win-def:object">
<sch:assert test="@object_ref=ancestor::oval-def:oval_definitions/oval-def:objects/win-def:ntuser_object/@id"><sch:value-of select="../@id"/> - the object child
element of a ntuser_test must reference a ntuser_object</sch:assert>
</sch:rule>
<sch:rule context="win-def:ntuser_test/win-def:state">
<sch:assert test="@state_ref=ancestor::oval-def:oval_definitions/oval-def:states/win-def:ntuser_state/@id"><sch:value-of select="../@id"/> - the state child element
of a ntuser_test must reference a ntuser_state</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:TestType">
<xsd:sequence>
<xsd:element name="object" type="oval-def:ObjectRefType"/>
<xsd:element name="state" type="oval-def:StateRefType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="ntuser_object" substitutionGroup="oval-def:object">
<xsd:annotation>
<xsd:documentation/>
<xsd:appinfo>
<sch:pattern id="win-def_ntuser_object_verify_filter_state">
<sch:rule context="win-def:ntuser_object//oval-def:filter">
<sch:let name="parent_object" value="ancestor::win-def:ntuser_object"/>
<sch:let name="parent_object_id" value="$parent_object/@id"/>
<sch:let name="state_ref" value="."/>
<sch:let name="reffed_state" value="ancestor::oval-def:oval_definitions/oval-def:states/*[@id=$state_ref]"/>
<sch:let name="state_name" value="local-name($reffed_state)"/>
<sch:let name="state_namespace" value="namespace-uri($reffed_state)"/>
<sch:assert test="(($state_namespace='http://oval.mitre.org/XMLSchema/oval-definitions-5#windows') and ($state_name='ntuser_state'))">State referenced in filter for
<sch:value-of select="name($parent_object)"/> '<sch:value-of select="$parent_object_id"/>' is of the wrong type. </sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:ObjectType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="oval-def:set"/>
<xsd:sequence>
<xsd:element name="behaviors" type="win-def:NTUserBehaviors" minOccurs="0"/>
<xsd:element name="key" type="oval-def:EntityObjectStringType">
<xsd:annotation>
<xsd:documentation>The key element describes a registry key to be collected. Note that the hive portion of the string should not be
included, as this data is not neccessary for the ntuser test and would normally reside in the HKCU hive.</xsd:documentation>
<xsd:appinfo>
<sch:pattern id="win-def_ntuserobjkey2">
<sch:rule context="win-def:ntuser_object/win-def:key[not(@operation='equals' or not(@operation))]">
<sch:assert test="not(preceding-sibling::win-def:behaviors[@max_depth])"><sch:value-of select="../@id"/> - the max_depth
behavior MUST not be used when a pattern match is used with a key entity.</sch:assert>
<sch:assert test="not(preceding-sibling::win-def:behaviors[@recurse_direction])"><sch:value-of select="../@id"/> - the
recurse_direction behavior MUST not be used when a pattern match is used with a key entity.</sch:assert>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="name" type="oval-def:EntityObjectStringType" nillable="true">
<xsd:annotation>
<xsd:documentation>The name element describes the name assigned to a value associated with a specific registry key. If an empty string is
specified for the name element, the registry key's default value should be collected. If the xsi:nil attribute is set to true, then
the object being specified is the higher level key. In this case, the name element should not be collected or used in analysis.
Setting xsi:nil equal to true on an element is different than using a .* pattern match. A .* pattern match says to collect every name
under a given hive/key. The most likely use for xsi:nil within a registry object is when checking for the existence of a particular
key, without regards to the different names associated with it.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element ref="oval-def:filter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="ntuser_state" substitutionGroup="oval-def:state">
<xsd:annotation>
<xsd:documentation>The ntuser_state element defines the different metadata associate with a ntuser.dat file. This includes the key, name, type, and value. Please refer to the
individual elements in the schema for more details about what each represents.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-def:StateType">
<xsd:sequence>
<xsd:element name="key" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>This element describes a registry key normally found in the HKCU hive to be tested.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="name" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>This element describes the name of a value of a registry key. If the xsi:nil attribute is set to true, then the name element should
not be used in analysis.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sid" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>This element holds a string that represents the SID of a particular user.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="username" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The user entity holds a string that represents the name of a particular user. In Windows, user names are case-insensitive. As a
result, it is recommended that the case-insensitive operations are used for this entity. In a domain environment, users should be identified in
the form: "domain\user name". For local users use: "computer name\user name".</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="account_type" type="win-def:EntityStateNTUserAccountTypeType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The account_type element describes if the user account is a local account or domain account.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="logged_on" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The logged_on element describes if the user account is currently logged on to the computer.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="enabled" type="oval-def:EntityStateBoolType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The enabled element describes if the user account is enabled or disabled.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="date_modified" type="oval-def:EntityStateIntType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Time of last modification of file. The string should represent the FILETIME structure which is a 64-bit value representing the number
of 100-nanosecond intervals since January 1, 1601 (UTC).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="filepath" type="oval-def:EntityStateStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>This element describes the filepath of the ntuser.dat file.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="last_write_time" type="oval-def:EntityStateIntType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The last time that the key or any of its value entries was modified. The value of this entity represents the FILETIME structure which
is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). Last write time can be queried on a key or
name. When collecting only information about a registry key the last write time will be the time the key or any of its entiries was written to.
When collecting only information about a registry name the last write time will be the time the name was written to. See the RegQueryInfoKey
function lpftLastWriteTime.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="type" type="win-def:EntityStateRegistryTypeType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The type entity allows a test to be written against the registy type associated with the specified registry key(s). Please refer to
the documentation on the EntityStateRegistryTypeType for more information about the different valid individual types.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="value" type="oval-def:EntityStateAnySimpleType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The value entity allows a test to be written against the value held within the specified registry key(s). If the value being tested
is of type REG_BINARY, then the datatype attribute should be set to 'binary' and the data represented by the value entity should follow the
xsd:hexBinary form. (each binary octet is encoded as two hex digits) If the value being tested is of type REG_DWORD or REG_QWORD, then the
datatype attribute should be set to 'int' and the value entity should represent the data as an integer. If the value being tested is of type
REG_EXPAND_SZ, then the datatype attribute should be set to 'string' and the pre-expanded string should be represented by the value entity. If the
value being tested is of type REG_MULTI_SZ, then only a single string (one of the multiple strings) should be tested using the value entity with
the datatype attribute set to 'string'. In order to test multiple values, multiple OVAL registry tests should be used. If the specified registry
key is of type REG_SZ, then the datatype should be 'string' and the value entity should be a copy of the string.</xsd:documentation>
<xsd:documentation>Note that if the intent is to test a version number held in the registry (as a reg_sz) then instead of setting the datatype to
'string', the datatype can be set to 'version'. This allows tools performing the evaluation to know how to perform less than and greater than
operations correctly.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="NTUserBehaviors">
<xsd:annotation>
<xsd:documentation>The NTUseryBehaviors complex type defines a number of behaviors that allow a more detailed definition of the ntuser_object being specified. Note that using these
behaviors may result in some unique results. For example, a double negative type condition might be created where an object entity says include everything except a specific
item, but a behavior is used that might then add that item back in.</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="max_depth" use="optional" default="-1">
<xsd:annotation>
<xsd:documentation>'max_depth' defines the maximum depth of recursion to perform when a recurse_direction is specified. A value of '0' is equivalent to no recursion, '1' means
to step only one directory level up/down, and so on. The default value is '-1' meaning no limitation. For a 'max_depth' of -1 or any value of 1 or more the starting key
must be considered in the recursive search.</xsd:documentation>
<xsd:documentation>Note that the default recurse_direction behavior is 'none' so even though max_depth specifies no limitation by default, the recurse_direction behavior turns
recursion off.</xsd:documentation>
<xsd:documentation>Note that this behavior only applies with the equality operation on the key entity.</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:integer">
<xsd:fractionDigits value="0"/>
<xsd:minInclusive value="-1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="recurse_direction" use="optional" default="none">
<xsd:annotation>
<xsd:documentation>'recurse_direction' defines the direction, either 'up' to parent keys, or 'down' into child keys to recursively search for registry keys. When recursing up
or down, one is limited by the max_depth behavior. Note that it is not an error if max_depth specifies a certain level of recursion and that level does not exist.
Recursing should only go as deep as available. The default value is 'none' for no recursion.</xsd:documentation>
<xsd:documentation>Note that this behavior only applies with the equality operation on the key entity.</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="none"/>
<xsd:enumeration value="up"/>
<xsd:enumeration value="down"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="windows_view" use="optional" default="64_bit">
<xsd:annotation>
<xsd:documentation>64-bit versions of Windows provide an alternate file system and registry views to 32-bit applications. This behavior allows the OVAL Object to specify which
view should be examined. This behavior only applies to 64-bit Windows, and must not be applied on other platforms. </xsd:documentation>
<xsd:documentation>Note that the values have the following meaning: '64_bit' – Indicates that the 64-bit view on 64-bit Windows operating systems must be examined. On a 32-bit
system, the Object must be evaluated without applying the behavior. '32_bit' – Indicates that the 32-bit view must be examined. On a 32-bit system, the Object must be
evaluated without applying the behavior. It is recommended that the corresponding 'windows_view' entity be set on the OVAL Items that are collected when this behavior is
used to distinguish between the OVAL Items that are collected in the 32-bit or 64-bit views.</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="32_bit"/>
<xsd:enumeration value="64_bit"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
<!-- =============================================================================== -->
<!-- ============================ NTUSER ITEM ================================== -->
<!-- =============================================================================== -->
<xsd:element name="ntuser_item" substitutionGroup="oval-sc:item">
<xsd:annotation>
<xsd:documentation>The windows ntuser item specifies information that can be collected from a particular ntuser.dat file.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval-sc:ItemType">
<xsd:sequence>
<xsd:element name="key" type="oval-sc:EntityItemStringType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>This element describes a registry key normally found in the HKCU hive to be tested.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="name" type="oval-sc:EntityItemStringType" minOccurs="0" maxOccurs="1" nillable="true">
<xsd:annotation>
<xsd:documentation>This element describes the name of a registry key. If the xsi:nil attribute is set to true, then the item being represented is the
higher level key. Using xsi:nil here will result in a status of 'does not exist' for the type, and value entities since these entities are not
associated with a key by itself.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sid" type="oval-sc:EntityItemStringType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>This element holds a string that represents the SID of a particular user.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="username" type="oval-sc:EntityItemStringType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The user entity holds a string that represents the name of a particular user. In Windows, user names are case-insensitive. As a
result, it is recommended that the case-insensitive operations are used for this entity. In a domain environment, users should be identified in
the form: "domain\user name". For local users use: "computer name\user name".</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="account_type" type="win-sc:EntityItemNTUserAccountTypeType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The account_type element describes if the user account(s) to test is/are local account(s), domain account(s), or to include both
local and domain accounts.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="logged_on" type="oval-sc:EntityItemBoolType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The logged_on element describes if the usre account(s) to test is/are currently logged on to the computeror not.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="enabled" type="oval-sc:EntityItemBoolType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The enabled_status element describes if the user account(s) to test is/are enabled or not.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="date_modified" type="oval-sc:EntityItemIntType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Time of last modification of file. The string should represent the FILETIME structure which is a 64-bit value representing the number
of 100-nanosecond intervals since January 1, 1601 (UTC).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="filepath" type="oval-sc:EntityItemStringType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>This element describes the filepath of the ntuser.dat file.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="last_write_time" type="oval-sc:EntityItemIntType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The last time that the key or any of its value entries was modified. The value of this entity represents the FILETIME structure which
is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). Last write time can be queried on a hive, key,
or name. When collecting only information about a registry hive the last write time will be the time the hive or any of its entiries was written
to. When collecting only information about a registry hive and key the last write time will be the time the key or any of its entiries was written
to. When collecting only information about a registry name the last write time will be the time the name was written to. See the RegQueryInfoKey
function lpftLastWriteTime.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="type" type="win-sc:EntityItemRegistryTypeType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Specifies the type of data stored by the registry key. Please refer to the EntityItemRegistryTypeType for more information about the
different possible types.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="value" type="oval-sc:EntityItemAnySimpleType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>The value entity holds the actual value of the specified registry key. The representation of the value as well as the associated
datatype attribute depends on type of data stored in the registry key. If the specified registry key is of type REG_BINARY, then the datatype
attribute should be set to 'binary' and the data represented by the value entity should follow the xsd:hexBinary form. (each binary octet is
encoded as two hex digits) If the registry key is of type REG_DWORD or REG_QWORD, then the datatype attribute should be set to 'int' and the value
entity should represent the data as an integer. If the specified registry key is of type REG_EXPAND_SZ, then the datatype attribute should be set
to 'string' and the pre-expanded string should be represented by the value entity. If the specified registry key is of type REG_MULTI_SZ, then
multiple value entities should exist to describe the array of strings, with each value element holds a single string. In the end, there should be
the same number of value entities as there are strings in the reg_multi_sz array. If the specified registry key is of type REG_SZ, then the
datatype should be 'string' and the value entity should be a copy of the string.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="EntityStateNTUserAccountTypeType">
<xsd:annotation>
<xsd:documentation>The EntityStateNTUserAccountTypeType restricts a string value to a specific set of values that describe the different types of accounts. The empty string is also
allowed to support empty elements associated with error conditions.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="oval-def:EntityStateStringType">
<xsd:enumeration value="local">
<xsd:annotation>
<xsd:documentation>Local accounts are accounts that were created directly on the machine being tested and should be in the form of
machinename\username</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="domain">
<xsd:annotation>
<xsd:documentation>Domain accounts are accounts that were created on a domain controller and should be in the form of domain\username</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="">
<xsd:annotation>
<xsd:documentation>The empty string value is permitted here to allow for detailed error reporting.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="EntityItemNTUserAccountTypeType">
<xsd:annotation>
<xsd:documentation>The EntityItemNTUserAccountTypeType restricts a string value to a specific set of values that describe the different types of accounts. The empty string is also
allowed to support empty elements associated with error conditions.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="oval-sc:EntityItemStringType">
<xsd:enumeration value="local">
<xsd:annotation>
<xsd:documentation>Local accounts are accounts that were created directly on the machine being tested and should be in the form of
machinename\username</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="domain">
<xsd:annotation>
<xsd:documentation>Domain accounts are accounts that were created on a domain controller and should be in the form of domain\username</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="">
<xsd:annotation>
<xsd:documentation>The empty string value is permitted here to allow for detailed error reporting.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>