Purpose	A CIFS front-end service must understand the Active-Directory (AD) hierarchy in its network. That is, the CIFS service must know where to find the correct DC for each domain in the AD forest. The ARX database requires a representation of the AD forest, with the IP addresses of the DCs that control each domain. Use the active-directory-forest command to start manually configuring one AD-forest representation on the ARX. Use no active-directory-forest to remove one AD-forest configuration from the switch.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	active-directory-forest forest-name no active-directory-forest forest-name   forest-name (1-256 characters) is the name you choose for the forest.
Default(s)	None
Guidelines	As an alternative to this command, you can automatically discover an AD forest in your network by using the active-directory update seed-domain command. After the forest is configured on the ARX, you can periodically use active-directory update forest to re-synchronize the ARX configuration with the actual AD-forest configuration. The active-directory-forest command starts the process of manually describing an AD forest to the ARX. This command places you in gbl-forest mode, where you identify all of the domains in the AD forest, along with the DCs that manage them. Use the forest-root command to identify each DC for the forest root. Domains in an AD forest have parent-child relationships based on their names. For example, the forest-root domain, myco.com, can have child domains named usa.myco.com and britain.myco.com. The usa.myco.com domain can have its own child domain named ne.usa.myco.com. From gbl-forest mode, use the child-domain command to identify a child domain. A forest can also support trees that are outside the roots domain. These are domains with two-way-transitive-trust relationships with one or more domains in the root tree. To continue the above example, a tree domain named nonprofit.org may also be trusted by myco.com, and it may have a child domain named euro.nonprofit.org. From gbl-forest mode, use the tree-domain command to identify an external tree domain. You use the child-domain command to assign a child to the tree domain; the name links each child to the correct parent.
Guidelines: Dynamic DNS	Kerberos authentication requires an up-to-date DNS database to map front-end CIFS services to their IP addresses. To facilitate DNS updates as CIFS services are added and removed, you can use the name-server command to identify a dynamic-DNS server for each domain in the forest. In many cases, the DC itself can also double as the name server for its domain.
Guidelines: Forest-to-Forest Trusts	For AD forests with two-way-trust relationships, where clients from one forest are allowed to access CIFS services from the other forest, you can use the active-directory forest-trust command to declare that trust relationship in the ARX configuration.
Guidelines: Removing an AD Forest	You cannot remove an AD-forest configuration if it contains any child domains or tree domains, or if it is part of a forest-to-forest trust. You can manually remove all of the forests child domains (with no child-domain) and tree domains (no tree-domain), or an active-directory update forest operation may automatically remove all of them. To remove any forest trust, use no active-directory forest-trust. After the last child domain, tree domain, an/or trust is removed, you can use no active-directory-forest.
Note: You cannot remove an AD forest if any CIFS service is joined to its root domain (see domain-join). From gbl-cifs mode, use the no cifs command to remove CIFS service, then remove the forest.
Samples	bstnA(gbl)# active-directory-forest sierra bstnA(gbl-forest[sierra])# ... creates a forest named sierra.   bstnA(gbl)# no active-directory-forest ADtrial bstnA(gbl)# ... removes a forest named ADtrial.
Related Commands	active-directory update seed-domain active-directory update forest forest-root child-domain name-server tree-domain active-directory forest-trust cifs domain-join enable (gbl-cifs, gbl-nfs) show active-directory

Purpose	Windows 2003 servers can support a two-way trust between AD forests. Clients from one forest can access CIFS services in the other, trusted, forest. You can use the active-directory forest-trust command to reflect this trust relationship in the ARX configuration. Use the no form of the command to remove the forest-to-forest trust between two forests.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	active-directory forest-trust forest-1 forest-2 no active-directory forest-trust forest-1 forest-2   forest-1 (1-256 characters) is one of the two forests in the trust relationship. This must have a Windows 2003+ server as its forest-root; earlier versions of Windows do not support forest-to-forest trusts. forest-2 (1-256 characters) is the other forest in the trust relationship, with the same restrictions as above.
Default(s)	None
Guidelines	This command is unnecessary if you use kerberos auto-realm-traversal. Both AD forests must be configured as active-directory-forests on the ARX, must have Windows 2003+ DCs as their forest-roots, and must have a forest-function level of Windows 2003+ for this command to succeed. An error message explains any such configuration errors, and the command fails. You can use the active-directory update seed-domain command to automatically discover an AD forest in your network and add it to the ARX configuration. The forest-to-forest trust must exist externally, at the DCs, before you use this command to record the trust in the ARX configuration. This records a two-way trust between the two forests. Clients from forest-1 can access CIFS services in forest-2, and clients in forest-2 can also access CIFS services in forest-1. The forest-to-forest trust is direct, not transitive. Suppose a trust existed between forest A and forest B, and another trust existed between forest B and forest C. This does not imply that a client in forest A can access a CIFS service in forest C. A new trust must be established between forests A and C before the clients in one forest can access any services in the other. This reflects the forest-to-forest-trust behavior in Windows servers. Because all forest trusts are direct, at least one CIFS service (see cifs) must be configured in one of the forests (forest-1 or forest-2) for the trust to be relevant.
Guidelines: Selective Authentication	If any of the forest trusts in the Windows network use Selective Authentication, the ARX must use a special algorithm to support clients in those forests. Use the kerberos auto-realm-traversal command to support remote forests with Selective Authentication set. As mentioned above, the kerberos auto-realm-traversal command makes the current command unnecessary; it enables automatic discovery of all trust relationships.
Samples	bstnA(gbl)# active-directory forest-trust medarch.org ri.com establishes a two-way trust between two AD forests, medarcv and ri.com.   bstnA(gbl)# no active-directory forest-trust medarch.org ri.com removes the above trust relationship. After this command, clients in the ri.com forest can no-longer access any CIFS service in the medarcv forest, nor can clients in medarcv access services in ri.com.
Related Commands	active-directory update seed-domain active-directory-forest forest-root kerberos auto-realm-traversal show active-directory show active-directory status

Purpose	A CIFS front-end service must understand the Active-Directory (AD) hierarchy in its network. That is, the CIFS service must know where to find the correct DC for each domain in the AD forest. The ARX database requires a full representation of the AD forest, with the IP addresses of at least one DC per domain. If the actual forest changes, you can use the active-directory update forest command to discover the changes and add them to the ARX configuration.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	active-directory update forest forest-root proxy-user proxy [domain-controllers max-dcs] [site-name site] [verbose] [tentative]   forest-root (1-255 characters) is the name of the forest-root domain. This is often the name of the AD-forest itself, too. proxy (1-32 characters) is a proxy-user with credentials for accessing the root domains DC(s). The ARX queries the DC for the names of other domains in the same AD forest. max-dcs (optional, 1-100) sets a maximum number of DCs used in each domain. The ARX queries its DNS server to discover all the DCs in each domain; if the DNS server returns more DCs than max-dcs, the ARX takes the top DCs from the DNS list. The ARX uses the order returned from DNS. site (optional, 1-64 characters) identifies the AD site for the ARX. This name is defined on a DC with the Active Directory Sites and Services plugin. The site name is case insensitive, so portland and PORTLAND are equivalent. If you omit this, the ARX software uses the AD site configured for the ip proxy-address subnet. Use this option if the ADs site configuration does not include the proxy-IP subnet. verbose (optional) causes the command to show the results of the forest discovery as it progresses. tentative (optional) makes the ARX perform the AD-forest discovery without creating the actual active-directory-forest configuration.
Default(s)	max-dcs - all DCs returned from each DNS query. site - the AD site configured on the external Active Directory for the proxy-IP subnet. This default requires that the proxy-IP subnet is defined in the AD; you can add the subnet on a DC with the Active Directory Sites and Services plugin.
Guidelines	You can only use this command for an AD forest that is already configured on the ARX. To automatically discover an AD forest and add it to the ARX configuration, use the active-directory update seed-domain command. You can also use active-directory-forest to manually add a forest to the ARX configuration, or to manually edit an existing forests configuration. The ARX uses a DNS query to find the DC(s) in this domain, then queries one of the DCs for the other domains in the forest. The DNS server that you use must be able to translate for all DCs in the target forest. Use the ip name-server command to add a DNS server to the ARX configuration. The AD-update operation creates a report named active-directory-forest_name.rpt, where forest_name is the forest that you identified in the command. The CLI displays the name of the report after you issue the command. Use show reports type AdUp to list all AD-update reports. To follow the progress of the AD-update operation, you can use tail reports report-name follow. Use show reports report-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands. If you want to truncate the report before it finishes, use the truncate-report command. See Figure 18.1 on page 18-9 for a sample report. Use the show active-directory command to show the configuration of the AD forest, as recorded on the ARX. To see the current state of all DCs in the forest, use the show active-directory status command.
Guidelines: Domain Types	The report and the show commands all identify a domain type for each of the forests domains. The update process categorizes all new domains as it finds them. Domains in an AD forest have parent-child relationships based on their names. For example, the domain, myorg.org, can have a child domain named mygroup.myorg.org. In this relationship, myorg.org is called the forest-root domain and mygroup.myorg.org is a child domain. An AD forest can also support trees that are outside the forest roots tree. These are domains with two-way-transitive-trust relationships with one or more domains in the root tree, but their domain names are entirely different. They are called tree domains. To continue the above example, a tree domain named acme.com may also be in the AD forest, and it may have a child domain named coyote.acme.com.
Guidelines: Dynamic DNS	Kerberos authentication requires that the forests DNS servers have up-to-date mappings of the ARX-CIFS services and their IP addresses. To facilitate DNS updates as the ARX-CIFS services are added and removed, you can use the gbl-forest name-server command to identify a dynamic-DNS server for each domain in the forest. The AD-update process does not discover dynamic-DNS servers. In many cases, the DC itself can also double as the name server for its domain.
Guidelines: Trusts Between Forests	For AD forests with two-way-trust relationships, where clients from one forest are allowed to access CIFS services from the other forest, you can use the kerberos auto-realm-traversal command to automatically discover all such trust relationships. Alternatively, you can use the active-directory forest-trust command to declare a forest-to-forest trust relationship in the ARX configuration.
Samples	bstnA# active-directory update forest wells.me.org proxy-user ny_admin   Report File : active-directory-wells.me.org.rpt updates an AD forest named wells.me.org and adds the forest to the ARX configuration. See Figure 18.1 for a sample report.   bstnA# active-directory update forest vt.com proxy-user ny_admin tentative   Report File : active-directory-VT.COM.rpt performs a tentative update of the vt.com forest. This re-discovers the forest without changing the ARX configuration. Details about the forest discovery appear in the AD-update report.
Related Commands	ip name-server proxy-user kerberos auto-realm-traversal active-directory-forest name-server active-directory forest-trust show active-directory show active-directory status

Purpose	Use the child-domain command to manually add a child domain (or one of its DCs) to an Active Directory forest. If this domain has no children of its own, you can use no child-domain to remove it. You can also use no child-domain to remove a redundant DC from the child domains configuration.
Mode	gbl-forest
Security Role(s)	storage-engineer or crypto-officer
Syntax	child-domain domain-name dc [preferred] no child-domain domain-name dc   domain-name (1-256 characters) is the child domain name. This must be in the same domain namespace as its parent domain; for example, if the parent domain is nonprofit.org, this child domain could be mycharity.nonprofit.org. dc is the IP address (for example, 192.168.25.56) of the domain controller (DC) for this child domain. If redundant DCs are hosting the domain, repeat this command (using the same domain-name) with the address of the redundant dc. preferred (optional) declares that you prefer to use this DC over others in the same domain. Whenever the ARX Kerberos process chooses from multiple DCs in the same domain, it chooses from the DCs labeled preferred first.
Guidelines	This command may not be necessary if you use active-directory update seed-domain to automatically discover all child domains in the AD forest. A child domain must have a parent, which must be the forest root (forest-root), a tree domain (tree-domain), or another child domain. As stated earlier, the child-domain name must begin with the name of its parent domain. A child domain can be the parent to other child domains. Redundant DCs may manage a child domain. Re-use the child-domain command (with the same domain name) for each redundant DC. If you prefer to use one or more DCs in the domain over the others, use the preferred flag to identify those DCs. The Kerberos process selects its active DCs from the preferred list. The process only stops using a DC if its connection fails; the kerberos health-check threshold command selects a timeout threshold for DC connections. The Kerberos process does not choose any DC outside the preferred list unless all of the preferred DCs have timed out. You can use show active-directory status to see which DCs are currently active for each domain. To remove a DC from the preferred list, you can re-run the child-domain command without the optional preferred flag. You can use this flag to change the active DC at any time.
	There are two circumstances under which you can use no child-domain: the domain has no child domains under it, or the domain has one or more redundant DCs configured and you want to remove one of them.
Samples	bstnA(gbl-forest[sierra])# child-domain ne.sierra.acopia.com 10.5.2.1 adds the ne.siera.acopia.com child domain to the sierra forest.   bstnA(gbl-forest[sierra])# child-domain ne.sierra.acopia.com 10.5.2.14 preferred adds another DC to the ne.siera.acopia.com domain, and declares it preferred. The ARX attempts to use this DC before it uses the one from the previous example.   bstnA(gbl-forest[sierra])# child-domain ne.sierra.acopia.com 10.5.2.14 takes the DC off of the preferred list for the ne.siera.acopia.com domain. If there are no other preferred DCs for this domain, the ARX selects a DC from the non-preferred list (10.5.2.1 or 10.5.2.14, from these examples).
Related Commands	active-directory-forest active-directory update seed-domain kerberos health-check threshold domain-join forest-root show active-directory tree-domain

Purpose	Use the forest-root command to identify the forest-root domain (or one of its domain controllers) in the Active-Directory forest. Use the no form of the command to remove the forest root, or one of the redundant domain controllers (DCs) that manages it.
Mode	gbl-forest
Security Role(s)	storage-engineer or crypto-officer
Syntax	forest-root domain-name dc [preferred] no forest-root domain-name dc   domain-name (1-256 characters) is the domain name for the forest root. dc is the IP address (for example, 192.168.25.56) of the forest roots DC. If redundant DCs are hosting the root domain, repeat this command (using the same domain-name) with the address of each redundant dc. preferred (optional) declares that you prefer to use this DC over others in the same domain. Whenever the ARX Kerberos process chooses from multiple DCs in the same domain, it chooses from the DCs labeled preferred first.
Default(s)	None
Guidelines	This command may not be necessary if you use active-directory update seed-domain to automatically discover all domains in the AD forest. Adding a forest root is the second step in manually creating an Active Directory forest. The forest-root command identifies the root domain for the forest, and one DC that manages the domain. If redundant DCs manage the root domain, you can use the command once for each DC. An AD forest requires one forest root. You can use child-domain to manually add one or more child domains to the forest root. The parent/child relationship between domains is established by their names: if mycountry.gov is the root domain, all of its child domains must reside in that domain (for example, mystate.mycountry.gov or myprovince.mycountry.gov, but not otherstate.org). To add a disjoint tree of domains, use the tree-domain command. This is a tree of domains that is outside the root domain, but has a trust relationship with the domains in the forest roots tree. Just as with the forest root, you can use the child-domain command to add child domains to any tree domain. If multiple DCs are configured to manage the forest root, you can use no forest-root to remove one of them at any time. Otherwise, the no forest-root command removes the entire root domain. To remove the forest-root domain, it cannot have any child domains, no CIFS services can be joined to the domain (through domain-join), and there can be no forest-trust relationships between this forest and any other forest (using no active-directory forest-trust).
Guidelines: Choosing the Active DC	If redundant DCs manage a domain, you can choose the DC(s) that you prefer for active use. Re-use the forest-root command (with the same domain name) for each redundant DC. You can use the optional preferred flag to identify preferred DCs. The Kerberos process uses DCs from the preferred list whenever possible. The process only stops using a DC if its connection times out; the kerberos health-check threshold command selects the timeout threshold. The Kerberos process does not choose any DC outside the preferred list unless all of the preferred DCs have timed out. You can use show active-directory status to see which DCs are currently active for each domain, including the forest-root domain. To remove a DC from the preferred list, you can re-run the forest-root command without the optional preferred flag. You can use this flag to change the active DC at any time.
Samples	bstnA(gbl-forest[siera])# forest-root siera.acopia.com 10.5.1.23 preferred sets the forest-root domain to siera.acopia.com, and declares the DC at 10.5.1.23 to be preferred over other DCs in the same domain.   bstnA(gbl-forest[siera])# forest-root siera.acopia.com 10.5.1.23 re-sets the forest root, but removes the DC from the preferred list.
Related Commands	active-directory-forest active-directory update seed-domain kerberos health-check threshold child-domain domain-join show active-directory tree-domain active-directory forest-trust

Purpose	This command is relevant to an NTLM Secure Agent, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI mode and command. At an installation that uses NTLM or NTLMv2 with unconstrained delegation, the ARX uses the Secure Agent as an NTLM proxy. You install the Secure-Agent software on a Windows DC (domain controller). When a client accesses CIFS on the ARX, the switch forwards the NTLM-authentication request to the Secure Agent. The Secure Agent accesses the password database on the Windows DC, and it tells the ARX whether or not the authentication succeeded. Use this command to specify the IP address of the Windows DC where the ARX Secure Agent is installed For multiple domains, enter the IP address of each DC that hosts an instance of Secure Agent.
Mode	gbl-ntlm-auth-srv
Security Role(s)	crypto-officer
Syntax	ip address server-address no ip address   server-address (0.0.0.0-255.255.255.255) is the IP address of the Secure Agents DC. Use the no form of the command to remove the IP address/host.
Default(s)	None
Guidelines: Using Constrained Delegation Instead of a Secure Agent	As mentioned above, Secure Agents (and this command) are unnecessary if all of your CIFS services use constrained delegation. Constrained delegation is implemented at a local DC. You can use the probe delegate-to command to retrieve some necessary configuration information to set up constrained delegation for your CIFS services. For sites where some DCs are older than Windows Server 2003 (which introduced constrained delegation), this CLI mode and command are required for NTLM support.
Guidelines: Running this Command	ARX Secure Agent software is installed on a Windows DC. You can install the Secure Agent on multiple DCs to support NTLM/NTLMv2 authentication for multiple domains. Use this command to specify the IP address of the DC that runs an instance of Secure Agent. You can use the port command to specify the port at which the Secure Agent listens, assuming this port was also changed at the Secure Agent interface. See the ARX Secure Agent Installation Guide for more information about the Secure Agent. Ensure there is a network link between the switch and each Windows domain controller that hosts an instance of Secure Agent.
Sample	gffstnA(gbl)# ntlm-auth-server ggh-dc gffstnA(gbl-ntlm-auth-srv[ggh-dc])# ip address 192.168.25.109 specifies the IP address of the DC where the ggh-dc agent runs.
Related Commands	ntlm-auth-server port show ntlm-auth-server

Purpose	On a Windows domain controller (DC), you can configure a forest-to-forest trust with Selective Authentication, where you list the clients in Forest A who have access privileges in Forest B. If the ARX is in Forest B, these privileged clients cannot use its services unless you enable auto-realm traversal on the ARX. Auto-realm traversal is an ARX algorithm that supports selective authentication. Auto-realm traversal also allows automatic support of all forest-to-forest trusts in your Active Directory, without explicitly stating them in the ARX configuration. This is a recommended feature. You can use the no kerberos auto-realm-traversal command to stop supporting this feature, and make it impossible for clients to authenticate from an external forest with a Selective Authentication policy. This is not generally advisable, and should only be done on the advice of F5 Support. Use the affirmative form of the command to return to the default Kerberos algorithm. This supports all Kerberos clients, including clients on the other side of a selective-authentication trust, and it automatically supports all forest-to-forest trusts.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	no kerberos auto-realm-traversal kerberos auto-realm-traversal
Default(s)	kerberos auto-realm-traversal
Guidelines	This is a system-wide parameter; the Kerberos software uses the same realm-traversal algorithm for all clients. If you use the default setting, you do not need to explicitly declare any forest-to-forest trusts with the active-directory forest-trust command. This is recommended. If you choose to disable this feature, you can use the active-directory forest-trust command to inform the ARX of each forest-to-forest trust in your network. However, clients cannot connect to the ARX through a forest-to-forest trust with selective authentication.
Sample	bstnA(gbl)# kerberos auto-realm-traversal supports clients on the other side of a forest-to-forest trust with Selective Authentication enabled.
Related Commands	active-directory forest-trust

Purpose	The Kerberos software regularly sends a simple LDAP query to all of the DCs in its AD forest, and times the response from each DC. If a DC takes too long to respond, the Kerberos software declares it offline and sends an SNMP trap. You can use the kerberos health-check threshold command to determine the maximum allowable response time from any DC. Use the no form of the command to return to the default response time.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	kerberos health-check threshold milliseconds no kerberos health-check threshold   milliseconds (optional 500-10,000) is the maximum amount of time allowed for a DC response.
Default(s)	2,000 (2 seconds)
Guidelines	This is a system-wide parameter; the maximum time applies to all DCs in all AD forests. For a complete list of all of these DCs, use the show active-directory command. The LDAP query tests the DCs ability to perform lookups in the AD database. This is designed as an unobtrusive verification of the DCs basic functions. The Kerberos process sends an LDAP request every 60 seconds. After the Kerberos software declares a DC offline, it continues to send the LDAP request at the same rate; if the DC responds within the allotted time, the Kerberos process declares it online again. The show active-directory status command displays the current state of all DCs known to the ARX.
Samples	prtlndA(gbl)# kerberos health-check threshold 5000 sets a 5-second threshold for DC responses.   stoweA(gbl)# no kerberos health-check threshold sets the threshold to the default on the stoweA system.
Related Commands	active-directory update seed-domain show active-directory show active-directory status

Purpose	Kerberos authentication requires accurate DNS configuration for all CIFS services. To facilitate this, CIFS services can use dynamic DNS to register their host names with your DNS servers and update those servers whenever their hostname-to-IP mapping changes. Use the name-server command to identify a dynamic-DNS name server. You can use no name-server to remove a name server.
Mode	gbl-forest
Security Role(s)	storage-engineer or crypto-officer
Syntax	name-server domain-name ip-address no name-server domain-name ip-address   domain-name (1-255 characters) is the name of the AD domain that is supported by the name server, below. ip-address is the IP address of the name server. This is frequently the same as the DC that manages the domain, identified with forest-root, child-domain, or tree-domain.
Default(s)	None
Guidelines	Basic Domain Name Service (DNS) is defined in two RFCs, 1034 and 1035. The ARX also supports the Microsoft-specific authentication extensions specified in RFC 3645. We recommend that every domain in the AD forest has at least one name server configured. (The show active-directory command shows all domains in an AD forest.) If a domains DNS records do not correctly identify a front-end CIFS service, the domains Windows clients cannot use Kerberos to authenticate with it. You can use this command more than once to identify multiple name servers for the same AD domain. A CIFS service in that domain tries the first-configured service, then the second, and so forth until it successfully registers its IP address in an A record. After it succeeds, it stops registering; the external DNS servers are presumed to duplicate their A records independently, as configured by the DNS administrator. From gbl-cifs mode, use dynamic-dns to DNS-register the front-end CIFS service. A CIFS service only registers with a name server when it is enabled (with enable (gbl-cifs, gbl-nfs)).
Samples	bstnA(gbl-forest[siera])# name-server siera.acopia.com 10.5.1.23 bstnA(gbl-forest[siera])# name-server siera.acopia.com 10.5.1.29 identifies two dynamic-DNS servers for the siera.acopia.com domain.   bstnA(gbl-forest[siera])# no name-server siera.acopia.com 10.5.1.29 removes one name server from the siera.acopia.com domain.
Related Commands	active-directory-forest show active-directory forest-root child-domain tree-domain dynamic-dns

Purpose	This command is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI command. Use this command to configure an NTLM authentication database. The NTLM authentication database contains a list of valid usernames/passwords (up to 10). If a client is in the database, the ARX can use preset credentials to authenticate user access to back-end CIFS filers and shares. Use the ntlm-auth-db command to instantiate a new NTLM authentication database.
Mode	gbl
Security Role(s)	crypto-officer
Syntax	ntlm-auth-db name no ntlm-auth-db name   name (1-64 characters) is a name that you choose for the Windows NTLM authentication demo database. Use the no form of the command to remove an NTLM authentication database.
Default(s)	None
Guidelines: Using Constrained Delegation Instead of a Secure Agent	As mentioned above, this command is unnecessary if all of your CIFS services use constrained delegation. Constrained delegation is implemented at a local DC. You can use the probe delegate-to command to retrieve some necessary configuration information to set up constrained delegation for your CIFS services. For sites where some DCs are older than Windows Server 2003 (which introduced constrained delegation), either this command or ntlm-auth-server is required for NTLM support.
Guidelines: Running the Command	This command puts you into gbl-ntlm-auth-db mode, where you configure the NTLM demo database parameters. Use the user (gbl-ntlm-auth-db) command to configure up to 10 users/encrypted passwords associated with the NTLM authentication demo database. You need one valid username/password for each supported client (up to 10). If you have more than one namespace that supports the same domain, you can assign the same database to both namespaces. Use the ntlm-auth-db (gbl-ns) command to assign an NTLM authentication database to a namespace. If you remove an authentication database with the no form of the command, clients cannot access CIFS shares in a namespace that uses the database.
Samples	bstnA(gbl)# ntlm-auth-db MYDEMO bstnA(gbl-ntlm-auth-db[MYDEMO])# creates a new NTLM authentication database, MYDEMO.   bstnA(gbl)# no ntlm-auth-db OLDDEMO removes an NTLM authentication database, OLDDEMO, from the switch.
Related Commands	ntlm-auth-db (gbl-ns) user (gbl-ntlm-auth-db)

Purpose	This command is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI command. The ARX Secure Agent can be separately installed on a Windows domain controller (DC). If a front-end CIFS service uses unconstrained delegation, it requires the Secure Agent to assist with NTLM and/or NTLMv2 authentication for its clients. (This command has no effect on Kerberos authentication.) Use the ntlm-auth-server command to begin configuring a Secure Agent server at the ARX. Use the no form of the command to remove a Secure-Agent-server configuration from the switch.
Mode	gbl
Security Role(s)	crypto-officer
Syntax	ntlm-auth-server name no ntlm-auth-server name   name (1-128 characters) is a name that you choose for the Secure Agent server. Create a Secure Agent server for each DC that hosts a Secure Agent.
Default(s)	None
Guidelines	The CLI prompts for confirmation before creating a new NTLM-server configuration object; enter yes to continue.
Note: If the front-end CIFS Service uses constrained delegation, introduced with Windows Server 2003, the Secure Agent (and this command) is unnecessary. An administrator with Domain Administrator privileges can go to the DC and configure constrained delegation for this CIFS service. You can use the probe delegate-to command to find all back-end filers behind a CIFS service, which the DC administrator adds to the CIFS services delegate-to list. Once the CIFS service is set up this way at the DC, the services clients can authenticate with NTLM, NTLMv2, and/or Kerberos.
Guidelines (Cont.)	For CIFS services with unconstrained delegation, one NTLM-server configuration object is required for each Secure Agent installed on each DC. This command creates a new NTLM server and places you in ntlm-auth-server mode, where you configure the Secure Agent servers attributes: Use the ip address (gbl-ntlm-auth-srv) command to enter the IP address of the DC running the Secure Agent. Use the port command to assign a port on which the Secure Agent listens for authentication requests from the switch. Use the windows-domain (gbl-ntlm-auth-srv) command to associate a domain name with this NTLM authentication server. This is a Windows domain that is managed by the servers DC host. Use the exact domain name that clients use for authentication. Use the password command to provide the password for accessing the Secure Agent authentication server.
	After you configure the servers attributes, you assign it to one or more namespaces. Use the ntlm-auth-server (gbl-ns) command in gbl-ns mode to assign an NTLM-authentication server to a namespace. The Secure Agent assists the namespace with NTLM/NTLMv2 authentication for its CIFS clients. You can assign multiple NTLM-authentication servers to a single namespace, and you can assign a single NTLM-authentication server to multiple namespaces. If you have redundant DCs for a given Windows Domain, we recommend installing a Secure Agent on all of them and using this command to add each of them to the ARX configuration. If you assign more than one to a namespace, the namespace software tries each of them until it successfully connects. The namespace software starts with the Secure Agent running the highest software revision. If you remove a Secure Agent server with the no form of the command, NTLM/NTLMv2 clients cannot access CIFS shares in a namespace that uses this Secure Agent instance. Kerberos authentication is unaffected, though a fall-back to any version of NTLM fails if there is no Secure Agent for the requested domain. The namespaces proxy-user (used for autonomous volume operations, such as import and file migrations) does not require an NTLM server to authenticate. For more information about Secure Agent, see the ARX Secure Agent Installation Guide.
Samples	gffstnA(gbl)# ntlm-auth-server ggh-dc   This will create a new NTLM Server.   Create NTLM Server 'ggh-dc'? [yes/no] yes gffstnA(gbl-ntlm-auth-srv[ggh-dc])# instantiates a Secure Agent server, server1.   bstnA(gbl)# no ntlm-auth-server dc1 removes the Secure Agent server, dc1, from the ARX configuration.
Related Commands	show ntlm-auth-server ip address (gbl-ntlm-auth-srv) port windows-domain (gbl-ntlm-auth-srv) password

Purpose	This command is relevant to an NTLM Secure Agent, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI mode and command. At an installation that uses NTLM or NTLMv2 authentication with unconstrained delegation, the ARX uses the Secure Agent as an NTLM proxy. Use this command to enter a password to be shared by the Secure Agent and the ARX. The Secure Agent and the ARX use this password to verify each others identity when they first establish a TCP connection.
Mode	gbl-ntlm-auth-srv
Security Role(s)	crypto-officer
Syntax	password
Default(s)	None
Guidelines: Using Constrained Delegation Instead of a Secure Agent	As mentioned above, Secure Agents (and this command) are unnecessary if all of your CIFS services use constrained delegation. Constrained delegation is implemented at a local DC. You can use the probe delegate-to command to retrieve some necessary configuration information to set up constrained delegation for your CIFS services. For sites where some DCs are older than Windows Server 2003 (which introduced constrained delegation), this CLI mode and command are required for NTLM support.
Guidelines: Running the Command	The CLI prompts you for the password, then prompts again to re-enter the password. Enter 4-64 characters. The password does not appear in the show running/global-config output as plain text, but as a base64-encoded password. The password you enter in this command must match the password configured at the ARX Secure Agent. The switch uses Secure Agent software to assist in CIFS authentication requests received from clients to back-end CIFS storage devices. See the ARX Secure Agent Installation Guide for information about installing and managing Secure Agent software.
Sample	gffstnA(gbl)# ntlm-auth-server ggh-dc gffstnA(gbl-ntlm-auth-srv[ggh-dc])# password Password: ******** Validate Password: ******** gffstnA(gbl-ntlm-auth-srv[ggh-dc])#
Related Commands	ntlm-auth-server show ntlm-auth-server

Purpose	A Windows-management-authorization (WMA) group is a list of Windows clients who can use Windows-management applications (such as MMC or snapshots) in one or more namespaces. The permit command establishes a permissible management action for the current WMA group. Use no permit to remove a permission from the group.
Mode	gbl-mgmt-auth
Security Role(s)	crypto-officer
Syntax	permit {share | session | open-file | snapshot | all} {monitor | any}   no permit {share | session | open-file | snapshot | all}     share | session | open-file | snapshot | all chooses the object of this permission: share selects CIFS-service shares, as well as non-shared volumes that are eligible to be added as CIFS shares. With any permissions (see below), members of this group can add and delete shares, too. session represents client sessions that are currently connected to the CIFS service. A member client can potentially see all other client sessions if the group has the monitor permission (below). With the any permission, the members can also potentially disconnect other clients. open-file chooses open files. If this has monitor permission, a group member can see these files; with any permission, a member can close files, too. snapshot selects the directory for accessing a volumes snapshots. WMA group members, when they access the volume through CIFS, can only see the snapshot directory if you set the monitor permission for this. The any permission has the same effect. all selects all of the above.
	monitor | any shows what the member clients can do with the object(s): monitor allows read-only access. This limits group members to listing (not changing) a CIFS services shares, sessions, open files and/or snapshots. any allows read-write access, so that member clients add, delete, close, and/or shut down the objects as appropriate. This has no additional affect on snapshots, which can only be monitored.
Default(s)	no permit share no permit session no permit open-file
Guidelines	Depending on the management permissions for the group, its members may be able to add new shares, view open files, and/or disconnect other client sessions. Use this command to set the specific permissions for this group; invoke the command multiple times to establish different permission levels for each object. Use the user (gbl-mgmt-auth) command to add Windows clients to the group. Use the show windows-mgmt-auth command to display the configuration for a WMA group. To apply a WMA group to a namespace, use windows-mgmt-auth (gbl-ns). You can apply multiple groups to the same namespace. Any CIFS service in front of this namespace uses these WMA groups if it has remote management/browsing enabled. From gbl-cifs mode, use browsing to enable remote management/browsing for a CIFS service. The WMA groups members only see the results of this command if they connect after you invoke it.
Guidelines: Permissions Required for MMC Option to Delete Shares	MMC software finds all session connections to a share before it deletes the share. The MMC delete share operation therefore fails with an error if it does not have permission to find the shares session connections. Use this extra command to allow MMC to find session connections: permit session monitor (The permit session all command also works for MMC.) This is in addition to the following command, which permits the client to remove the share: permit share all
Samples	bstnA(gbl-mgmt-auth[fullAccess])# permit all any allows the fullAccess group to perform any management actions on shares, open files, and client sessions.   bstnA(gbl-mgmt-auth[readOnly])# permit share monitor bstnA(gbl-mgmt-auth[readOnly])# permit session monitor permits members of the readOnly group to see all shares and client sessions, but not to change them in any way.   bstnA(gbl-mgmt-auth[snapViewers])# permit snapshot monitor permits members of the snapViewers group to see the snapshot directory through CIFS.   bstnA(gbl-mgmt-auth[fullAccess])# no permit open-file disqualifies the fullAccess group from viewing or changing open files though MMC or similar applications.
Related Commands	windows-mgmt-auth user (gbl-mgmt-auth) show windows-mgmt-auth windows-mgmt-auth (gbl-ns) browsing

Purpose	This command is relevant to an NTLM Secure Agent, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI mode and command. At an installation that uses NTLM or NTLMv2 authentication with unconstrained delegation, the ARX uses the Secure Agent as an NTLM proxy. Use this command to enter the TCP port (number) on which Secure Agent listens for authentication requests from the switch. Use the no form of the command to remove the current port number.
Mode	gbl-ntlm-auth-srv
Security Role(s)	crypto-officer
Syntax	port port no port   port (optional; 1-65535) is the port number on which Secure Agent listens for authentication requests from the switch.
Default(s)	25805
Guidelines: Using Constrained Delegation Instead of a Secure Agent	As mentioned above, Secure Agents (and this command) are unnecessary if all of your CIFS services use constrained delegation. Constrained delegation is implemented at a local DC. You can use the probe delegate-to command to retrieve some necessary configuration information to set up constrained delegation for your CIFS services. For sites where some DCs are older than Windows Server 2003 (which introduced constrained delegation), this CLI mode and command are required for NTLM support.
Guidelines: Running the Command	The Secure Agent server uses the specified port for NTLM-authentication transactions with the switch. The port number must match the port number specified when the Secure Agent software was installed on a Windows Domain Controller. If you do not enter a port number, the default port is used. See the ARX Secure Agent Installation Guide for more information.
Sample	gffstnA(gbl)# ntlm-auth-server ggh-dc gffstnA(gbl-ntlm-auth-srv[ggh-dc])# port 25805 sets the Secure Agent servers port number to 25805.
Related Commands	ntlm-auth-server ip address (gbl-ntlm-auth-srv)

Purpose	This command is relevant to an NTLM authentication database, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation. Use this command to display the configured NTLM-authentication demo databases.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show ntlm-auth-db [name]   name (1-64 characters) is the name of an NTLM authentication demo database. If no name is specified, this command shows names for all configured NTLM-authentication demo databases.
Guidelines	With the name argument, the command shows the username(s) and namespace(s) that use this database. Use the user (gbl-ntlm-auth-db) command to add a user to the database. Use the ntlm-auth-db (gbl-ns) command to assign the database to a namespace.
Sample	bstnA> show ntlm-auth-db   Name --------------------------------------- ntlmMap2 ntlmMap3   bstnA> show ntlm-auth-db ntlmMap2   Name --------------------------------------------------------- ntlmMap2   Users --------------------------------------------------------- techspecialist     Mapped to the Following Namespaces --------------------------------------------------------- cifsNamespace1
Related Commands	ntlm-auth-db ntlm-auth-db (gbl-ns) user (gbl-ntlm-auth-db)

Purpose	This command is relevant to an NTLM authentication server, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation. At an installation that does not support constrained delegation, the ARX uses the Secure Agent as an NTLM/NTLMv2 proxy. Use the show ntlm-auth-server command to display the configuration and statistics from one or more configured Secure Agent servers.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show ntlm-auth-server [name] [detailed]   name (optional, 1-128 characters) is the name of a Secure Agent server instance. If no name is specified, this command shows statistics for all configured Secure Agent servers. detailed (optional) generates detailed output, with success and failure counts from all current connections to the Secure Agent(s).
Guidelines: Using Constrained Delegation Instead of a Secure Agent	As mentioned above, Secure Agents (and this command) are unnecessary if all of your CIFS services use constrained delegation. Constrained delegation is implemented at a local DC. You can use the probe delegate-to command to retrieve some necessary configuration information to set up constrained delegation for your CIFS services. For sites that can follow this recommendation, you can use show statistics domain-controller to retrieve NTLM-authentication statistics. For sites where some DCs are older than Windows Server 2003 (which introduced constrained delegation), a Secure Agent is required for NTLM support and this command is relevant.
Guidelines: Summary Output	For the summary output, this command includes the following categories: Name is the name of this Secure Agent server instance, as configured with the ntlm-auth-server command. Version identifies the Software Release of the Secure Agent software. Server is the IP address of the Secure Agent server host system. If this is incorrect, you can use the ip address (gbl-ntlm-auth-srv) command to change it. Domain Name is the associated Windows Domain. If this is incorrect, you can use the windows-domain (gbl-ntlm-auth-srv) command to correct it. Pre-Win2k Domain is the short name of the above domain, for domains that existed before the release of Windows 2000. As above, you can use the windows-domain (gbl-ntlm-auth-srv) command to correct this in the ARX database. Capabilities is NTLM, NTLM, NTLMv2, Session Key, or Unknown. The Session Key flag indicates that the Secure Agent can support SMB signing (see cifs filer-signatures and signatures). Status is one of the following: Reachable is the status for a healthy Secure Agent. Unreachable indicates a connection problem. Check the connection to the Secure Agent with show exports, expect traceroute, and/or ping. Password Mismatch means that the password configured at the ARX (with the password command) is different from the password configured in the Secure Agents management applet. The ARX Secure Agent Installation Guide explains how to reset the password at the Secure Agents management applet. If another error appears, contact F5 Support for analysis.
Guidelines: Detailed Output	The detailed keyword causes the command to download detailed statistics from the Secure Agent(s). These are high-level statistics followed by a table of counters for every current connection to a Secure Agent. If you selected all Secure Agents, a separate SECURE AGENT STATISTICS page appears for each of them. The high-level statistics include the following: Agent IP is the IP address of the Secure Agents host DC. Agent Port is the TCP port where the Secure Agent is listening for ARX queries. Uptime shows the amount of time since the last restart of the Secure Agent application. Current Connections is the number of ARX systems currently connected to the Secure Agent. Failed connection attempts and Successful connection attempts summarize the connection statistics. Account Scan Interval is the time between scans of the DCs SAM database, in seconds. The Secure Agent uses this scanned data to assist the ARX with its NTLM/NTLMv2 authentications. Software Version is the release number for the Secure Agent software. Capabilities is NTLM, NTLM, NTLMv2, Session Key, or Unknown., as above. Connection #1 lists specific details about the first connection to the server including the source IP address, bytes transmitted, successful or failed client authentications, and filer response generation statistics. The client in these statistics is an ARX (typically, the current ARX), and the Source IP in the output is the ip proxy-address that the ARX used to connect to the Secure Agent. Connection #2, and any additional connections shown, list details specific to that connection to the server.
Samples	gffstnA> show ntlm-auth-server lists all configured Secure Agent servers. See Figure 18.2 on page 18-32 for sample output.   gffstnA> show ntlm-auth-server ggh-dc shows high-levels statistics about one Secure Agent server, ggh-dc. See Figure 18.3 on page 18-32 for sample output.   gffstnA> show ntlm-auth-server detailed shows detailed statistics about all Secure Agent servers. See Figure 18.4 on page 18-32 for sample output.
Related Commands	ntlm-auth-server ntlm-auth-server (gbl-ns)

Purpose	A Windows-management-authorization (WMA) group is a list of Windows clients with permissions to use Windows-management applications (such as MMC). Use this command to show the members and permissions for this type of group.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show windows-mgmt-auth [name]   name (optional; 1-64 characters) is the name of a specific WMA group. If no name is specified, this command shows all WMA groups.
Guidelines	The output for this command shows the following information for each WMA group: Windows Authorization Policy is the name of the WMA group, specified in the windows-mgmt-auth command. The user list appears next, as a table with one row per user: User Name and Domain Name describe one client in the group. Use user (gbl-mgmt-auth) to add or remove a client. If there is a pre-Windows 2000 name for the domain, it appears in the Domain Name field in parentheses. The last table shows the management permissions for the group, one permission per row. Each row has two fields: Managed Object is Share, Session, Open-file, Snapshot, or All. The permission (below) applies to this is the type of object. Permitted Operation is Monitor or Any. Monitor means that WMA-group clients can view the Managed Objects (shares, client sessions, open-files, or snapshots). Any means that the clients can change them, too (except snapshots, which are always read-only). Use permit (gbl-mgmt-auth) to add or remove a permission.
Samples	bstnA> show windows-mgmt-auth shows all WMA groups on this system. See Figure 18.5 for sample output.   bstnA> show windows-mgmt-auth fullAccess shows one WMA group, fullAccess. See Figure 18.6 on page 18-35 for sample output.
Related Commands	windows-mgmt-auth user (gbl-mgmt-auth) permit (gbl-mgmt-auth)

Purpose	Some Active-Directory (AD) domains are outside the domain namespace, but have a trust relationship with domains in the forest. These are called tree domains. Use the tree-domain command to add a tree domain to the AD forest. Use the no form of the command to remove a tree domain, or one of the redundant DCs that manages it.
Mode	gbl-forest
Security Role(s)	storage-engineer or crypto-officer
Syntax	tree-domain domain-name dc [preferred] no tree-domain domain-name dc   domain-name (1-256 characters) is the tree domain name. This does not require any parent in the forest. dc is the IP address (for example, 192.168.25.56) of the domain controller (DC) for the tree domain. If redundant DCs are hosting the domain, repeat this command (using the same domain-name) with the address of the redundant dc. preferred (optional) declares that you prefer to use this DC over others in the same domain. Whenever the ARX Kerberos process chooses from multiple DCs in the same domain, it chooses from the DCs labeled preferred first.
Default(s)	None.
Guidelines	This command may not be necessary if you use active-directory update seed-domain to automatically discover all child domains in the AD forest. Before you use this command, use the above command (or forest-root) to add a root to the Active Directory forest. The tree-domain command adds a disjoint tree to the forest, outside of the forests domain namespace. For example, if the forest has a root domain of telco.com with two child domains, na.telco.com and asia.telco.com, you could establish a tree domain outside the namespace, myphone.org. The tree domain is presumed to have a two-way-transitive-trust relationship with one of the domains in the root forest. If redundant DCs manage the tree domain, re-use the tree-domain command (with the same Domain name) for each redundant DC. If you prefer to use one or more DCs in the domain over the others, use the preferred flag to identify those DCs. The Kerberos process uses the DC(s) from the preferred list as its active DC(s). The process only stops using a DC if its connection times out; the kerberos health-check threshold command selects the timeout threshold. The Kerberos process does not choose any DCs outside the preferred list unless all of the preferred DCs have timed out. You can use show active-directory status to see which DCs are currently active for each domain. To remove a DC from the preferred list, you can re-run the tree-domain command without the optional preferred flag. You can use this flag to change the active DC at any time.
Guidelines (Cont.)	You can use the child-domain command to add a child to this tree domain. The parent/child relationship is created through the domain names (aparent.com can be the parent to achild.aparent.com). If the tree is managed by redundant DCs, you can use no tree-domain to remove one of them from the configuration. Otherwise, the no command removes the tree domain entirely; you must remove all of the trees child domains before you can do this.
Samples	bstnA(gbl-forest[medarch])# tree-domain ne.medarch.org 172.16.124.73 preferred adds the ne.medarch.org tree domain to a forest. This also declares this DC to be preferred over others in the same domain.   bstnA(gbl-forest[medarch])# tree-domain ne.medarch.org 172.16.124.73 has the same effect as the previous example, but removes the DC from the preferred list.
Related Commands	active-directory-forest active-directory update seed-domain kerberos health-check threshold child-domain domain-join forest-root show virtual service

Purpose	A Windows-management-authorization (WMA) group is a list of Windows clients with permissions to use remote Windows-management applications, such as MMC. The user command adds a client to the current WMA group. Use no user to remove a user from the group.
Mode	gbl-mgmt-auth
Security Role(s)	crypto-officer
Syntax	user name windows-domain fqdn [pre-win2k-name old-style-domain] no user name windows-domain domain-name   name (1-64 characters) is a valid Windows user. domain-name (1-64 characters) is the users domain name, exactly as the client types it for authentications. We recommend using the fully-qualified domain name (FQDN) for this field. If the client uses the FQDN (such as mygroup.org) to authenticate, they can use Kerberos; if the client uses the older NetBIOS name from the first part of the FQDN (such as MYGROUP), the client can only use some form of NTLM. old-style-domain (optional, 1-15 bytes, no periods) is the legacy, NetBIOS name of the Windows domain, if it is different from the default (below). The default should suffice for most situations; this option should only rarely be necessary. Clients who authenticate with this pre-Windows 2000 name can also use MMC; for example, if the pre-Windows 2000 name is GROUP for the mygroup.org domain, an MMC client could authenticate as GROUP/juser or mygroup.org/juser.
Default(s)	old-style-domain - The old-style name discovered with active-directory update seed-domain. If the old-style name was never discovered for this domain, the ARX uses the first part (before the first ., up to 15 characters) of the FQDN in the domain-name.
Guidelines	Depending on the management permissions for the group, they may be able to add new shares, view open files, and/or disconnect other client sessions. Use the permit (gbl-mgmt-auth) command to set the specific permissions for this group. Use this command multiple times to add multiple users to the group. Use the show windows-mgmt-auth command to display the configuration for a WMA group. To apply a WMA group to a namespace, use windows-mgmt-auth (gbl-ns). You can apply multiple groups to the same namespace. Use browsing to enable Windows management for a CIFS service.
Samples	bstnA(gbl-mgmt-auth[fullAccess])# user jquser windows-domain MEDARCH.ORG adds a user to the WMA group, fullAccess.   bstnA(gbl-mgmt-auth[readOnly])# no user test5 windows-domain MEDARCH.ORG removes a user from the readOnly group.
Related Commands	windows-mgmt-auth permit (gbl-mgmt-auth) show windows-mgmt-auth windows-mgmt-auth (gbl-ns) browsing

Purpose	This command is relevant to an NTLM authentication database, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI mode and command. Use this command to enter up to 10 usernames and passwords associated with the NTLM authentication database. If a client entry is in the database, the ARX can use the preset credentials to authenticate connections for access to back-end CIFS filers.
Mode	gbl-ntlm-auth-db
Security Role(s)	crypto-officer
Syntax	user dbuser no user dbuser   dbuser (1-64 characters) is one authorized Windows user.
Default(s)	None
Guidelines	The CLI prompts for the users password twice. You need one valid username and password for each supported client (up to 10). Use the no form of the command to remove a user from the current database.
Samples	bstnA(gbl-ntlm-auth-db[MYDEMO])# user sales Password: ******** Validate Password: ******** creates the user, sales, associated with the MYDEMO database   bstnA(gbl-ntlm-auth-db[MYDEMO])# no user sales removes the user, sales associated with the MYDEMO database.
Related Commands	ntlm-auth-db

Purpose	This command is relevant to an NTLM Secure Agent, which is only necessary behind a cifs service that uses unconstrained delegation (or is not joined to its domain). Best practices dictate that you use constrained delegation, as described in the domain-join documentation, and avoid this CLI mode and command. At an installation that uses NTLM or NTLMv2 with unconstrained delegation, the ARX uses the Secure Agent as an NTLM proxy. Use this command to assign the domain name to a Secure Agent server. Use the no form of the command to remove the domain name for this Secure Agent, thereby disabling it.
Mode	gbl-ntlm-auth-srv
Security Role(s)	crypto-officer
Syntax	windows-domain domain-name [pre-win2k-name old-style-domain] no windows-domain   domain-name (1-64 characters) is the Windows Domain to which you assign a Secure Agent instance (authentication server). When a client authenticates to an ARX CIFS service, the client uses this Secure Agent if they use this domain name. old-style-domain (optional, 1-15 characters, no periods) is the name of the legacy Windows domain, if it is different from the default (below). The default should suffice for most situations; this option should only rarely be necessary. Clients who authenticate with the pre-Windows 2000 name can also use this Secure Agent.
Default(s)	old-style-domain - The old-style name discovered with active-directory update seed-domain. If the old-style name was never discovered for this domain, the ARX assumes that the old-style name is the first part (before the first ., up to 15 characters) of the FQDN in the domain-name.
Guidelines: Using Constrained Delegation Instead of a Secure Agent	As mentioned above, Secure Agents (and this command) are unnecessary if all of your CIFS services use constrained delegation. Constrained delegation is implemented at a local DC. You can use the probe delegate-to command to retrieve some necessary configuration information to set up constrained delegation for your CIFS services. For sites where some DCs are older than Windows Server 2003 (which introduced constrained delegation), this CLI mode and command are required for NTLM support.
Guidelines: Running the Command	The domain name is the Windows domain where the Secure Agent software is installed (for each domain controller that hosts Secure Agent). Use the longest domain name that clients use for their authentications. For example, if clients authenticate with porthos.musketeer.gov domain as well as the shorter porthos name, you should create an authentication server for porthos.musketeer.gov. The ARX uses the single authentication-server object for the domain name and all shorter variations of the same domain name. For domains with a completely-different pre-Win2k name, such as GUARD3 as an the early name for porthos, use the pre-win2k-name option. The separate authentication server should use the same ip address (gbl-ntlm-auth-srv) to point to the same DC. If you remove the domain name with the no form of this command, clients cannot access CIFS shares in a namespace that uses this instance of Secure Agent.
Sample	gffstnA(gbl)# ntlm-auth-server serverFQDN gffstnA(gbl-ntlm-auth-srv[serverFQDN])# windows-domain ggh.medarch.org assigns a Secure Agent instance to the ggh.medarch.org Windows Domain, and to the old-style NHCIFS domain name.
Related Commands	ntlm-auth-server ip address (gbl-ntlm-auth-srv) show proxy-user

Purpose	A Windows-management-authorization (WMA) group is a list of Windows clients with permissions to use Windows-management applications (such as MMC) in one or more CIFS namespaces. Use the windows-mgmt-auth command to create a WMA group. Use no windows-mgmt-auth to remove a WMA group.
Mode	gbl
Security Role(s)	crypto-officer
Syntax	windows-mgmt-auth name no windows-mgmt-auth name   name (1-64 characters) is a name you choose for the group.
Default(s)	None
Guidelines	This command places you in gbl-mgmt-auth mode, where you then add one or more Windows clients and the management permissions for all of them. Use the user (gbl-mgmt-auth) command to add a Windows user to the group. Use the permit (gbl-mgmt-auth) command to add management permissions for these users, such as permission to add CIFS shares, close CIFS files, or view snapshot directories from Windows. Any CIFS client can list all configured CIFS shares from a CIFS service, whether or not he or she is a member of a WMA group. WMA-group members, given the proper permissions, can also see all volumes behind a CIFS service; this provides a menu for adding new shares to the service. Use the show windows-mgmt-auth command to display the configuration for a WMA group. To apply a WMA group to a namespace, use windows-mgmt-auth (gbl-ns). You can apply multiple groups to the same namespace. Use browsing to enable Windows management for a CIFS service.
Samples	bstnA(gbl)# windows-mgmt-auth fullAccess bstnA(gbl-mgmt-auth[fullAccess])# starts the configuration of WMA group, fullAccess.   bstnA(gbl)# no windows-mgmt-auth testMMC removes a WMA group from the system.
Related Commands	user (gbl-mgmt-auth) permit (gbl-mgmt-auth) show windows-mgmt-auth windows-mgmt-auth (gbl-ns) browsing