FileZerver releases V04.00 and V04.00.01 are now available for download for firmware update of Cyclone 2+ boards using the admin "Firmware Update" web page, ZerverView, or FTP, in files fzi0400.bin and fzi0401.bin. These releases can only be used on Cyclone 2+ boards, with 8MB of flash memory. The older Cyclone 2 boards have only 4MB of flash. Major Changes for V04.00 -- With the larger flash space available, product development and enhancement can continue. -- A newer version of the code for Windows networks using CIFS/SMB protocol, with "Active Directory" features, Samba 2.2.8a, has been used. (This version is a step or two back from the cutting-edge of Samba development.) FileZerver has long had the ability to migrate users and groups from a single Windows-NT (or later) machine (usually a Windows Domain PDC-Primary-Domain-Controller) acting as a password server. The "Active Directory" features allow users, groups, and password-checking to be done by a Windows-Domain -- PDC or any BDC-Backup-Domain-Controller -- and includes cross-domain trust possibilities. For more information, see the "Active Directory" Features section below. -- For Macintosh networks, encrypted login is supported again. (This feature had to be removed from the 4MB-flash releases due to size constraints when the Mac code, netatalk for AFP-Apple-File-Protocol, was upgraded.) -- The Status/System page will show the "Main Board" type as "Cyclone 2+". -- From a factory-defaults reset, security is on, remove-inactive-users is off, and (although ftp is still enabled) anonymous-ftp is off. Security-enable is needed for the "Active Directory" features to have any use. -- All ten natural languages are still supported for administrator web pages, but new messages (related to "Active Directory") are in English only. Help pages for the administrator pages are in English only. Additional Changes for V04.00.01 -- -- The major change is a new/better version of the code for Macintosh running AFP-Apple-File-Protocol, netatalk-1.6.3. -- The major fix involves swap space. In V04.00, if a "Virtual Memory" partition is created, it will be put in use. If there are several "Virtual Memory" partitions on different drives, and one of them is deleted, the others will be put in use. However, on re-boot, the "Virtual Memory" partitions were not automatically put in use. They would appear with status "Needs to be deleted". V04.00.01 corrects this problem. Upgrades -- These versions require 8MB flash memory on a Cyclone 2+ board. They cannot be run on a Cyclone 1 or Cyclone 2 without the flash expansion. Attempts to download and upgrade to the wrong hardware should meet with error messages. If a way is found around the error messages, the result will be a Cyclone which does not boot, with a "bad firmware" indication (status light blinks red 3 times). If you have a Cyclone 2 board with 4MB flash memory, your hardware can be upgraded. Please contact NetZerver customer support at 1-623-587-1284. If you have a Cyclone 2+ board with 8MB of flash but running one of the 4MB firmware releases, you can upgrade to this firmware, but some extra steps are needed. Please contact NetZerver customer support at 1-623-587-1284. "Active Directory" features -- The following text is adapted from the on-line help for the Windows-networks CIFS protocol configuration -- "CIFS", Common Internet File System (formerly known as SMB and sometimes referenced by the name of the Unix/Linux program which handles the protocol, Samba), allows access by Windows machines to network resources, including FileZerver. It supports the Windows view of naming and finding network nodes, identifying users, authenticating passwords, and enforcing access permissions to files and folders. User IDs Handling userids and passwords is the feature which has the most configuration possibilities and the most interaction with other features. On FileZerver using CIFS protocol, to identify and authenticate userids, there are several possibilities -- -- Userids created on the FileZerver, with the password defined (initially) using the admin web page "Security-Users-Add" and password-checking done by the FileZerver. There is a limit of 1000 userids and 125 groups, which are used to set Share-access permissions on the "Share Security" admin web page, and can be used to create ACL-Access-Control-List entries with the "File/Folder Security" admin web page. -- Userids that exist on a Windows-Domain, with password-checking done by a single "Password Server," generally a WiNT or W2K machine which is the PDC-Primary-Domain-Controller for the Windows-Domain. This method has been available in earlier FileZerver releases, and requires only the name of the Windows-Domain and the NetBIOS name of the Password-Server machine. (Earlier releases also required the IP-address of the Password-Server machine.) After a successful userid and password check, a FileZerver userid would be automatically created, if it did not already exist, along with appropriate groups. These user and group names then appear just like FileZerver-locally-created users and groups, and can be used in the same way to control Share permissions and create ACL-Access-Control-List entries using the FileZerver admin web pages. If the "Auto Create" options are selected, the userids and groups from the Windows-Domain would migrate to the FileZerver as each user would login. There is a limit of 1000 userids for the FileZerver. If there are more users than that limit known to the Password Server, and if Share-Permission can be properly specified using permissions for Groups within the Group-limit of 125, then the "Remove Inactive Users" feature can be selected on the "General System Information" web page (located there because it applies to both CIFS and NetWare Auto Create users). After migrating to the FileZerver after a login, an inactive userid can be removed, to be re-established after a later login which will use then-current group-membership and group-permissions for Share Security. -- Userids that exist on a Windows-Domain, with password-checking done either by the Windows-Domain PDC-Primary-Domain-Controller or any BDC-Backup-Domain-Controller. This "Active Directory" feature is new with the V4 Release, and requires, along with the Windows-Domain Name and the NetBIOS name of the PDC, a step to Join the FileZerver to the Domain. Even before the first userid login attempt, all of the userids and groups from the Windows-Domain will be visible on the FileZerver, but will appear differently -- "DOMAIN+name", in which "DOMAIN" is the Windows-Domain name and "name" is either a userid or group name, either pre-defined or that had been added to the Windows-Domain. These user and group names can be used with FileZerver admin web pages to control Share permissions and create ACL-Access-Control-List entries. As an Active Directory feature, ACL entries can also be created and manipulated with WiNT and W2K tools, without using FileZerver admin web pages. Because of the critical nature of the relationship between the Windows-Domain User and Group identifiers and the FileZerver userid and groupid numbers, there is currently a fairly small limit on the number of Windows-Domain Users, 256, and Groups, 64, that can be supported, and automatic "Remove Inactive Users" cannot be done. CIFS Configuration to use "Active Directory" features -- The configuration data needed for CIFS to use the "Active Directory" features is similar to that needed for the previously-available "Password Server" mechanism (for which there is more discussion below). The major difference is that an additional "Join Domain" step is needed. Ensure that CIFS is "Enabled". For "Password Check", select either "Will Join Domain" or "Domain Member". If "Will Join Domain" is selected, the value will be updated to "Domain Member" after a successful Join Domain operation. The field "Workgroup/Domain Name" must be the Windows-Domain name to join. The field "Primary Domain Controller (PDC) Name" is the NetBIOS name of the PDC to contact for the Join Domain operation. Fields "Master Browser" and "Run subnet's WINS Server" are generally set to No. See further discussion below for details. Fields "Auto Create Users" and "Auto Create Groups" should be set to No for Joining a Domain, since all of the Domain Users and Groups will be listed and usable after the Join Domain operation -- there will be nothing left to automatically create. If any of these values have been changed, hit "Save" so the new values will be saved with all other config data. After "Save", the "Join Domain" button can be selected, which leads to a web page for some additional data which is needed for the Join. The field "Domain user with add-node privilege" is a userid that already exists on the Windows-Domain which has enough privilege to be able to add a node to the Domain. This need not be the Domain Administrator. This userid and the password will be used only for the "Join Domain" operation and discarded after a successful Join, in contrast to the data which must be saved with the FileZerver config data. The data displayed for "Domain to join" and "PDC Primary Domain Controller" on this page are taken from the FileZerver config data. If the values are wrong or incomplete, then the config data are wrong or incomplete -- perhaps a "Save" was not successful on the screen for CIFS Server Configuration. The "Exit" button will return to that screen. The "Join Domain" button on this screen initiates the Join Domain operation, contacting the PDC, using the userid and password. The program name, "/bin/smbpasswd", parameters, and result messages are displayed. Userid and password problems can be corrected on this web page. Domain name and PDC name values can be changed on the CIFS Server config data screen by hitting "Exit". On success, the "Security-Users" and "Security-Groups" web pages will show a number of "DOMAIN+name" entries which can be used with "Security-Shares" to allow access to any mix of users and groups to any Share. A reboot will be needed if you changed the enabled-state, Domain Name, PDC Name, or the state of the Master Browser or WINS services. A reboot may be needed if the "Password Check" config data changed from "Password Server..." to "Domain Member" and there are already users connected using the earlier-selected mechanism. Join-Domain Problem Analysis Many problems involved with Joining a Windows-Domain and access by Domain Users and Groups may be illuminated by checking the "Status - User Login History" web page. Message for SMB protocol of "no machine acct password" refers to a value which is supposed to be shared between the FileZerver and the Windows-Domain. It indicates that the config data do not contain the result of a successful "Join Domain" operation. Message for SMB protocol "Node joined Domain DOMAINNAME" occurs for a successful "Join Domain" operation, identifying the Domain userid and the name of the PDC. This event is also noted in the "Status-Event-Log". Message for SMB protocol with status OK of "Domain DOMAINNAME" indicates a successful login that used the "Active Directory" features for Domain login. Message for SMB protocol with status Unauthorized saying "Deny SHARENAME" that occurs immediately after (same time-stamp) as a successful Domain login indicates that userid and password were checked by the Domain, login was successful, but permission to the requested share named "SHARENAME" was denied, probably due to Share permission (or its absence). Message for SMB protocol "reject by domain pw server" indicates the "Active Directory" features of the Windows Domain rejected a userid and password. The "reject by domain pw server" may be immediately followed (same time-stamp) by a message for SMB protocol with status OK for a userid with no message text at all. This occurs when a userid which is local to the FileZerver is first rejected by the Windows-Domain, and then found to be valid by the FileZerver. Message for SMB protocol with status OK for a userid saying "via password server" means that the successful login was done with the older mechanism, available with earlier FileZerver releases, in which the machine identified as the PDC is acting as a Password Server. The userid-password check request was not made as a member of a Windows-Domain. CIFS Configuration for Password Server and Local Userids To configure CIFS to use the older Password Server mechanism, or to restrict the FileZerver to use only FileZerver local userids, for the "Password Check" field select "Password Server and Local Userids". The "Workgroup/Domain Name" field must be set. This will be involved with browsing through lists of machine names, if nothing else. To specify a machine to act as a Password Server, enter the NetBIOS name in the field "Primary Domain Controller (PDC) Name", so named since the machine will most often be the PDC for the Windows-Domain. To restrict the FileZerver to local FileZerver userids only, leave this field empty. Fields "Master Browser" and "Run subnet's WINS Server" are generally set to No. See further discussion below for details. For operation with a Password Server, the fields "Auto Create Users" and "Auto Create Groups" will generally be Yes so that Users and Groups known to the Password Server will migrate to the FileZerver as needed. If any of these values have been changed, hit "Save" so the new values will be saved with all other config data. A reboot will be needed if you changed the enabled-state, Domain Name, PDC Name, or the state of the Master Browser or WINS services. Master Browser and WINS Server config, More Details -- "Master Browser" and "Run subnet's WINS Server" can generally be set to No. A node that can be a "Master Browser" keeps an approximate list of nodes that may provide Windows network services, which is used to provide a prompt display of names for a graphical interface or the DOS "net view" command (and might list nodes that are between up-times, or fail to list recently-activated nodes). If there are any W2K or WiNT machines in a Windows-Domain (as there would be when using "Active Directory" features), then the FileZerver should not be a Master Browser. If there is a Workgroup without any WiNT or W2K machines operating as a domain controller, perhaps a number of FileZervers in a Workgroup named "FileZervers", then one of them should be configured to be a Master Browser. A WINS-Windows-Internet-Name-Service Server maps NetBIOS names to IP addresses, and does so more efficiently than the ultimate fall-back strategy, which is to use broadcast messages to find a node with a given name. For small groups of nodes, broadcast messages work well enough, but somewhere between five and a hundred nodes, there can get to be a lot of broadcast messages. Also, a WINS Server could handle one or more Windows-Domains that extend beyond a single IP subnet, connected by routers that do not pass broadcast traffic. To configure a network to use a WINS server, you must inform each node of the existence and IP Address of that server (perhaps as part of the DHCP messages which assign IP addresses to a node). The WINS option is provided in V4 because this is a service that a FileZerver could have been running with earlier releases -- if a WINS server address was not provided (by static-address assignment or from the DHCP message), then a WINS service would be started. It would have been possible for a set of machines to be configured to use WINS running on a FileZerver, even though nothing was visible in the configuration of the FileZerver. With this configuration option, choosing to run a WINS server is now explicit. The field "Run subnet's WINS Server" should be set to Yes if there is a network of nodes that had used the FileZerver IP address for WINS with earlier releases, or if the network structure requires a WINS Server and the FileZerver would be the best candidate to provide that service.