Retro video games delivered to your door every month!
Click above to get retro games delivered to your door ever month!
X-Hacker.org- Novlib 3.30 Online Reference - <b> bindery functions overview</b> http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]
 Bindery functions overview
------------------------------------------------------------------------------
 In a local area network environment, it is necessary to identify resources
 and clients. A resource is anything that provides a service, such as a file
 server, print server, or database server, etc. A client is the user of the
 services provided by a resource. Each NetWare file server maintains a
 database of the resources and clients available on the network called the
 bindery.

 The fundamental benefit of the bindery is that it allows the design of an
 organised and secure operating environment. The bindery contains
 information on each client and is the foundation of NetWare's client
 security systems, including password protection, accounting and
 restrictions.

 The bindery also contains information about each resource on the network.
 For example, resources which advertise their services have their name and
 internetwork address stored in the bindery of each file server on the
 internetwork. Therefore, the bindery can also be used as a resource
 directory where clients can extract a listing of all resources available on
 the network, for example file servers, print servers, etc.

 The bindery is not limited to exclusive use by the NetWare operating
 system, but is a flexible database with an extensive programming interface,
 accessible using NOVLIB functions. Programs can access the bindery, using
 the NOVLIB bindery functions, to extract information about network users
 and resources. The bindery can also be used to store program-specific
 information. For example, the user and configuration information of a
 program could be stored in the bindery.

    Bindery components
    Bindery objects
    Bindery properties
    NetWare properties

 The bindery consists primarily of components called objects and properties.

 Bindery objects

 A bindery object can be a user, user group, file server, print server, or
 any other logical or physical entity on the network that has been given a
 name. Each object has an associated set of characteristics called
 properties, as represented in the figure below.

 <<Diag>>

 Each object can have multiple properties associated with it. Each property
 may have an attached value which contains the actual data associated with
 the property.

 Bindery properties

 For example, a user's set of properties may include a password, an account
 balance, or a list of groups of which the user is a member.

 Bindery property values

 The actual data associated with a property is stored in the property's
 VALUE. A user's password, for example, is stored in the property value
 associated with the password property. An example bindery object and its
 associated properties is shown in the following figure.

 <<Diag>>

 Bindery constraints

 Being similar to a relational database, the bindery can contain any
 combination of up to 65,000 bindery objects and properties. A large bindery
 is therefore slower to access than a small bindery, which will affect the
 overall performance of the network. The bindery also has no locking
 mechanism, so when updates are made to the bindery, there is no attempt to
 co-ordinate requests among multiple workstations.

 Bindery files

 The bindery files are NET$BIND.SYS and NET$BVAL.SYS on Netware file servers
 of version 2x. The NET$BIND.SYS file contains objects and properties. The
 NET$BVAL.SYS file contains the property values.
 On Netware file servers of version 3.0 or greater, the bindery files are
 NET$OBJ.SYS, NET$PROP.SYS and NET$VAL.SYS. The NET$OBJ.SYS file contains
 the objects, the NET$PROP.SYS file contains the properties, and the
 NET$VAL.SYS file contains the property values.
 Each file server manages its own bindery files independently of the
 binderies of other file servers, which means that the resources and clients
 available to one file server may not be available to other file servers.
 Even when similar objects are defined in more than one bindery, the unique
 ID of each object differs from one bindery to another; an object is given a
 unique ID when it is created.

 Bindery access

 Programs can query the network for information about named network objects
 through NOVLIB's bindery function calls. In addition to reading the
 bindery, programs can create bindery objects, add properties to bindery
 objects, and give values to the properties of bindery objects using NOVLIB
 bindery function calls. (See the end of this chapter for a list of NOVLIB
 bindery functions.)
 The ability of programs to read or write to the bindery depends upon the
 security access levels of both the object and the property to be accessed.
 Security is enforced by the operating system of the file server where the
 bindery resides.

 Bindery security

 Each file server administers the security for its local resources, services
 and client accounts through the bindery. The bindery has several levels of
 security which together provide a flexible yet secure operating
 environment. Each object and property in the bindery has an associated
 security access level, which controls the read and write access to a
 bindery object and its properties.
 Each bindery has a Supervisor object that is granted special bindery
 security privileges. The Supervisor is allowed to grant these special
 administrative privileges to other objects through the security equivalence
 feature which allows a bindery object to be granted the same access rights
 as another object. The security equivalence feature is also useful in
 defining user groups, a means of logically organising users into work
 groups. This allows the system Supervisor to simplify the security process.
 Generally, a user group is assigned specific directory access rights and
 users are added to the user group.

 Security levels

 The security level of the bindery controls the read and write access of
 others to a bindery object or property. Each bindery object has an
 associated object security level, and each property has an associated
 property security level. The object security and the property security are
 each two nibbles; the low-order nibble controls the read security and the
 high-order nibble controls the write security. The following values are
 defined for each nibble:

 Hex   Binary   Access      Description
  0 0000  Anyone   Access allowed to all clients, even if
             the client has not logged in to the file
             server.
  1 0001  Logged   Access allowed only to clients who
             have logged in to the file server.
  2 0010  Object      Access allowed only to clients who
             have logged in to the file server with
             the object's name, type and password.

  3 0011  Supervisor  Access allowed only to clients who
             logged in to the server as the
             Supervisor or as an object that has
             Supervisor equivalence.
  4 0100  NetWare  Access only allowed to the NetWare
             operating system.
 For example, a bindery object with an object security level of 49, 0x31
 (Supervisor write-Logged read) can be viewed by any client that has
 successfully logged in to the server, but can only have properties added to
 it by a client that is security-equivalent to the Supervisor. If this
 object has a property with a property security level of 51, 0x33
 (Supervisor write-Supervisor read), the property and its value can only be
 viewed or modified by a client that is security-equivalent to the
 Supervisor.

 Bindery objects

 The bindery is a collection of named objects. An object can be a user, user
 group, file server, print server, print queue, or any other logical or
 physical entity on the network that has been given a name. Each object has
 an object name, an object type, an object ID, a dynamic flag and an object
 security.
 The object name and object type uniquely identify the bindery object. The
 object ID number, a numeric value that is assigned to the object when it is
 created, also uniquely identifies the object. The static/dynamic flag
 indicates whether the object is dynamic or static. The object security
 determines whether other objects can access it.

    Object Structure
    Object ID   4 bytes
    Object Name 1-48 bytes
    Object Type 1 byte
    Static/Dynamic Flag  1 byte
    Write/Read Security  1 byte

 Object Name

 An object name is a zero delimited string of 1 to 47 characters and must
 contain only printable characters (21h through 7Dh). Control characters,
 spaces, slashes (/), backslashes (\), colons (:), semi-colons (;), commas
 (,), asterisks (*), question marks (?), and tildes (~) are invalid
 characters. Object names are recorded in uppercase in the bindery in
 NetWare 3.x, and case sensitively in NetWare 4.x.
 The asterisk (*) and question mark (?) are wild characters and can be used
 to specify a search pattern when scanning for bindery objects. An asterisk
 (*) matches 0 or more characters. Thus, the pattern "*" will match any
 object name. A question mark (?) matches exactly one character. Thus, the
 pattern "??" will only match two-character object names.

 Object Type

 The object type identifies the object as a specific type of client or
 resource. The most common defined NetWare object types are listed in the
 following figure.
          Object types
    Description          Object Type (hex)
    Unknown              0
    User                 1
    User Group              2
    Print Queue             3
    File Server             4
    Job Server              5
    Gateway              6
    Print Server               7
    Archive Queue           8
    Archive Server          9
    Job Queue               A
    Administration          B
    Remote Bridge Server       24
    Advertising Printer Server       47
    WILD                 FFFF (-1)

 The WILD object type (0xFFFF) is not an actual object type that would be
 associated with a bindery object. It is used when scanning the bindery if
 the actual object type is not known or is not relevant to the caller. The
 WILD object type may not be used when adding an object to the bindery.
 Object types up to 0x8000 are reserved by Novell for well-known object
 types. Other object types may be defined and used by your programs as
 needed. If you develop a program and wish to be allocated an object type,
 contact Novell for assignment of a well-known object type.
 Each object type has a set of specifications associated with it. An object
 created with one of the Novell-defined object types must adhere to the
 specifications that are defined for that particular object type. For
 example, an object that is declared as a user must have a password property
 to log in to the file server. A user is also required to have an
 ACCOUNT_BALANCE property to log in if the file server is charging for its
 services.

 Object Flag

 The object flag indicates the expected lifetime of an object. An object is
 either static (0x00) or dynamic (0x01). A static object is a long-term
 object that must be explicitly deleted from the bindery when it is no
 longer useful. An object of type user is a good example of a static object.
 A dynamic object is one that is created and deleted frequently, and
 therefore, is deleted when the file server is brought down and
 re-initialised. The dynamic flag is used by advertising servers which need
 to be dynamically added to, and deleted from, the binderies of other file
 servers.

 Object ID number

 Each bindery object is given a unique ID when it is created. This ID is a
 number which is used as a simple method of identifying an object without
 specifying the object's name and type. The object ID is only guaranteed to
 be unique within the bindery of a single file server. Also, the ID number
 does NOT identify the bindery of the file server in which an object is
 defined.

 Object Security

 The object security controls the read and write access of others to the
 bindery object. The low-order nibble determines who can read (scan for and
 find) the object. The high-order nibble determines who can write to (add
 properties to or delete properties from) the object. For example, an object
 security of 49, 0x31 (Supervisor write-logged read) indicates that any user
 logged in to the file server can find the object, but only the Supervisor
 can add a property to the object.

 Bindery properties

 Properties are named pieces of information attached to objects. Each
 bindery object may have one or more associated properties. For example, the
 user DAN (object type 0x01) might have associated with it the properties
 GROUPS_I'M_IN, ACCOUNT_BALANCE, and PASSWORD. Note that GROUPS_I'M_IN is
 not the name of a user group to which the object belongs. It is only the
 name of one category of information associated with that object. In the
 same way, ACCOUNT_BALANCE is not an actual numeric balance, and PASSWORD is
 not an actual password. Properties only identify categories of information
 associated with the object.

 NetWare properties

 NetWare has defined many different properties for many different purposes.
 Some properties contain further information about an object (e.g. the
 IDENTIFICATION property) while others are used to administer the network
 security system (e.g. the PASSWORD and SECURITY_EQUALS properties). All
 properties defined by Novell which contain numeric data (including set
 properties) are stored in high-low order.

 Standard properties

 Following the description of standard properties is a listing of the
 NetWare-defined properties.

 GROUP_MEMBERS Property

 The GROUP_MEMBERS property contains a list of users that are members of a
 user group. This property is attached to user group objects. The
 GROUP_MEMBERS property is a static/set property and has object read and
 Supervisor write security access levels.

 GROUPS_I'M_IN Property

 The GROUPS_I'M_IN property contains a list of user groups of which a user
 is a member. This property is attached to user objects. The GROUPS_I'M_IN
 property is a static/set property and has logged read and Supervisor write
 security access levels.

 IDENTIFICATION Property

 The IDENTIFICATION property contains the full name of a user or user group.
 This property is attached to user and user group objects. The
 IDENTIFICATION property is a static/item property and has logged read and
 Supervisor write security access levels.

 OPERATORS Property

 The OPERATORS property contains a list of objects that are authorised file
 server console operators. This property is attached to the file server's
 object. The OPERATORS property is a static/set property and has Supervisor
 read and Supervisor write security access levels.

 PASSWORD Property

 The PASSWORD property contains the encrypted password of an object. This
 property is attached to user objects. Any object that logs in to the file
 server is required to have the PASSWORD property. The PASSWORD property can
 be created with the NOVLIB UsrPasswordChange() function call.
 The PASSWORD property is a static/item property and has NetWare read and
 NetWare write security access levels. The PASSWORD property is hidden and
 cannot be accessed by scanning for properties.

 SECURITY_EQUALS Property

 The SECURITY_EQUALS property contains a list of objects to which an object
 is security equivalent. This property is attached to user and user group
 objects. The SECURITY_EQUALS property is a static/set property and has
 object read and Supervisor write security access levels.

 LOGIN_CONTROL Property

 The LOGIN_CONTROL property has a single segment value (128 bytes) which
 contains all the information as to when a user can login, if his password
 has expired, if his account balance is low etc. The file server checks this
 before allowing a user login.

    Offset   Field                   Size     Type
    0  Account Expiration Date       3 bytes  BYTE
    3  Account Disabled Flag         1 byte   BYTE
    4  Password Expiration Date      3 bytes  BYTE
    7  Grace Log Ins Remaining       1 byte   BYTE
    8  Password Expiration Interval  2 bytes  WORD
    10 Grace Log In Reset Value      1 byte   BYTE
    11 Minimum Password Length       1 byte   BYTE
    12 Max Concurrent Connections    2 byte   WORD
    14 Allowed Login Time Bitmap    42 bytes  BYTE
    56 Last Login Date and Time      6 bytes  BYTE
    62 Restriction Flag              1 byte   BYTE
    63 Unused                        1 byte   BYTE
    64 Maximum Disk Usage In Blocks  4 bytes  LONG
    68 Bad Login Count               2 bytes  WORD
    70 Next Reset Time               4 bytes  LONG
    74 Bad Login Address            12 bytes  BYTE

Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson