Posts Tagged ‘active directory’

Using ArchiveConnect with ExtremeZ-IP Network Reshare

Wednesday, June 6th, 2012

Introduction

ArchiveConnect is fully compatible with ExtremeZ-IP 8.0’s new Network Reshare capability. This feature expands the options for giving Macs access to archive volumes on SMB accessible storage and also provides an excellent workaround for known issues with Mac clients running OS X 10.6.7 and later accessing SMB/CIFS archive volumes.

Network Reshare and ArchiveConnect provide a solution for accessing file archives on NAS storage

Due to an issue in Mac OS X 10.6.7 and later, Macs connecting to SMB accessible archive volumes on file servers or NAS storage are not able to properly recall files. This issue is fully detailed in this related knowledge base article.

By utilizing ExtremeZ-IP Network Reshare to make file archives, previously only available through SMB/CIFS connections, available to Macs using the standard AFP file sharing protocol, this issue can be avoided and Mac file recall behavior is properly managed by ArchiveConnect over the AFP connection.

Additional ArchiveConnct features included in ExtremeZ-IP also provide advantages to using AFP Network Reshare vs. using direct SMB access from Mac clients. An example is a configurable color label that indicates which files shown in the Finder are currently offline.

NetApp specific benefits to using ArchiveConnect with Network Reshare volumes

Before ExtremeZ-IP 8.0 with Network Reshare, Mac SMB access to NetApp archive volumes required the “Assume all SMB files are offline” setting to be configured in ArchiveConnect. This is not necessary when they are reshared through ExtremeZ-IP, so Mac users retain the ability to see thumbnail icons and quick look previews for files that are already online.

Accessing DFS files using ExtremeZ-IP Network Reshare

Wednesday, June 6th, 2012

Introduction

Prior to the release of version 8.0, ExtremeZ-IP supported Mac AFP access to Microsoft Distributed File System (DFS) file shares in several ways. Traditional ExtremeZ-IP DFS support requires one or more DFS namespaces to be added to the DFS tab in the ExtremeZ-IP Administrator’s Settings window. Then, Mac clients must be set up with one of the following options:

  • – The “Zidget” Dashboard widget – Used to browse DFS namespaces and mount specific resources within them.
  • – The ExtremeZ-IP “DFS Client” application – Used to allow mounting of DFS volumes in the Finder and browsing of the related DFS namespace, similar to the experience Windows presents to users.
  • – Manual modification of the Mac’s “auto_master” file – Provides the same experience as the DFS Client option, but requires editing a standard Mac config file rather than installing client software.

All of these options require client side software or changes on each Mac that requires access to DFS.

ExtremeZ-IP 8.0’s Network Reshare feature introduces an additional option for providing Macs with access to DFS resources. Network Reshare allows ExtremeZ-IP AFP file volumes to give access to folders located on other servers and NAS devices on your network. Macintosh clients continue to connect to ExtremeZ-IP using the standard AFP file sharing protocol, while ExtremeZ-IP utilizes the SMB/CIFS file sharing protocol to access files that are requested by Mac users from remote servers and NAS systems. By doing so, Mac users retain all the benefits of AFP file sharing while gaining access to resources that have traditionally only been available through SMB/Windows file sharing.

DFS shares can be configured as ExtremeZ-IP Network Reshare volumes. DFS target resolution simply occurs in the SMB reshare communication layer and Macs are able to seamlessly browse and access the reshared DFS resources presented in a standard AFP volume. No Mac client-side software or changes are required. Macs simply connect to ExtremeZ-IP AFP Network Reshare volumes in the Finder and can immediately browse the DFS namespace.

For more details on Network Reshare, see our Configuring Network Reshare support in ExtremeZ-IP knowledge base article.

Limitations

ExtremeZ-IP Server acts as DFS client
When hosting a Network Reshare DFS volume, the ExtremeZ-IP Windows server makes requests for resources located in DFS namespaces on behalf of the the Mac client. From the perspective of DFS, the Windows server itself is the client, not the actual Mac user making the request. For this reason, all DFS target selection and site costing will be negotiated for the Windows server, rather than the Mac client.

All Network Reshare communication is routed through the ExtremeZ-IP Windows server
Network Reshare routes all communication between your Mac clients and your DFS namespaces through the Windows server where ExtremeZ-IP is installed. This requires an extra network hop compared to the Mac client accessing DFS targets directly. For the best possible performance, it is recommended that ExtremeZ-IP is installed on a server with the fastest available NICs, and ideally this server has one or more NICs dedicated to communicating with the servers, NAS, or DFS namespaces being reshared.

ExtremeZ-IP Network Reshare feature and Network Reshare DFS volume configuration

For full details on configuring your ExtremeZ-IP server for Network Reshare and instructions on setting up a Network Reshare DFS volume, please see our Configuring Network Reshare support in ExtremeZ-IP knowledge base article.

Active Directory assigned home directories are not working in the mobilEcho client

Tuesday, November 8th, 2011

Introduction

mobilEcho includes the ability to automatically show a user’s Active Directory assigned home folder in the mobilEcho client app. These home directory locations are specified as a Windows file share (SMB) UNC path in the user’s Active Directory user account profile.

When setting up home directories in mobilEcho, it is important to consider the topology of your mobilEcho deployment.

mobilEcho includes a ‘Network Reshare’ feature, that allows a mobilEcho server to host a shared volume that gives access to data located on a second file server. The mobilEcho server uses the SMB/CIFS protocol to connect to the secondary file server.

If mobilEcho is installed directly on the server hosting your users’ Active Directory assigned SMB home folders, and a mobilEcho shared volume has been created with the same name and location as the SMB home folders shared volume, the mobilEcho UNC path to the home folders shared volume will be identical to the UNC path to the SMB home folders shared volume, and the UNC path specified in the user’s Active Directory profile home folder setting will be correct for both SMB access and mobilEcho access.

If you are using mobilEcho’s Network Reshare feature to give access to home directories on a secondary SMB file server, the SMB UNC path in a user’s Active Directory profile home folder setting will not match the mobilEcho UNC path, since mobilEcho servers access their home folders by connecting to a different server.

In this case, you will need to configure a Network Reshare Path Mapping, so that mobilEcho knows how to translate the SMB UNC path it gets from the Active Directory profile home folder setting to the mobilEcho UNC path that the mobilEcho client needs to know to connect to the home folder.

Configuring a Network reshare path mapping

  1. Click Servers & Folders in the top menu.
  2. Click the Add new path mapping button.
  3. Select the mobilEcho server where the mobilEcho network reshare shared volume is located. Then enter the name of the mobilEcho Shared Volume.
  4. Click Next.
  5. Enter the UNC Path that you would like to be redirected to the mobilEcho Shared Volume you specified in the previous step.
  6. Click Save.

Important note on server names in AD path vs. Network reshare path mapping

Because mobilEcho is matching on this path, the UNC Path needs to use the exact server name and SMB shared volume name as it appears in your users’ Active Directory user profile home folder setting. If an SMB home folder’s path in Active Directory uses a different name for the server than is entered in the path mapping setting (such as “\\fileserver.company.com\sharename” vs. “\\fileserver\sharename”) the home directory will not work in the mobilEcho client. If you’ve used more than one method for representing your server’s name in the Active Directory profile home folder setting for your users, you will need to create a path mapping for each variation on the server name.

INFO: Different Configurations of MassTransit Distribution List

Friday, May 28th, 2010

Summary:

MassTransit 6.0 implements the automatic Active Directory account management feature that allows setting up MassTransit contacts, forwarding privileges and so on automatically, based on existing Active Directory groups.

MassTransit 6.0 allows you to leverage the groups in your Active Directory tree to automatically create accounts and assign forwarding privileges. All automatically created MassTransit contacts will be of the Web Client type. Any existing Active Directory group can be designated as a part of the MassTransit Master List or the MassTransit Distribution List or both.

The feature is controlled by the configuration parameters in the MassTransitEngine.cfg configuration file. For more information about configuration of MDL and MML groups see INFO: Automatic Active Directory Account Management With MassTransit knowledge base article.

Description:

The new MassTransit Distribution List (MDL) capability defines who can send files to whom. The MDL is a regular Active Directory Security Group containing users and other groups. It can be an existing group or a specially created group. For members of the MDL MassTransit creates accounts on demand, only when they are needed, and makes these users available as valid destinations for files to be transferred. These on demand accounts are automatically purged after a period of time and are recreated when needed.

Users that are members of an AD group, which is part of the MDL, can send files to the other members of the same AD group and to any users on child levels. Bellow are three examples of MDL configuration that will help you understand how this feature works.

Example1:

In the first example, the MassTransit Distribution List – “MDL Group A” contains two AD groups – “Group Dog” and “Group Cat”. Each of the two groups has two members. The members of “Group Dog” can send files only to each other. The same is valid for the members of “Group Cat”.
For example: “Gracy AD user” can send files only to “Bob AD user”.

Example2:

In the second example, the MassTransit Distribution List – “MDL Group A” contains two AD groups – “Group Dog” and “Group Cat” and two AD users – “Jake AD user” and “Rex AD user”. These users can send files to each other, as well as to all users that are on child tree levels – the members of “Group Dog” and “Group Cat”. The members of “Group Dog” can send files only to each other. The same is valid for the members of “Group Cat”.
For example: “Rex AD user” can send files to ” Jake AD user”, “Gracy AD user”, “Bob AD user”, “Tim AD user”, and “John AD user”. “Tim AD user” can send files only to “John AD user”.

Example3:

In the third example, there is one additional AD group – “Group Snake” which belongs to “Group Dog”. “Sammy AD user” and “Sally AD user” are on the lowest tree level of the MDL, so they can send files only to each other. In contrast of the previous example, users from “Group Dog” can send files not only to each other but to members of “Group Snake” as well, since it is also a member of “Grou Dog”. “Rex AD user” and “Jake AD user” can send to all users.
For example: “Bob AD user” can send files to “Gracy AD user”, “Sammy AD user” and “Sally AD user”. “Tim AD user” can send files only to “John AD user”, since “Sammy AD user” and “Sally AD user” are not on a child tree level.

INFO: Configuring MassTransit For Use With Directory Services

Wednesday, January 6th, 2010

Summary:

MassTransit web client and application client (i.e., FTP Server) accounts can now be manually configured to have password authentication be conducted through Active Directory. Active Directory password management is available on Enterprise, Premier or Standard products for both Macintosh and Windows-based servers running MassTransit 5.1 or higher. The MassTransit Log Viewer can now be enabled to allow any user with a valid Active Directory account, who is in a defined group, to view the MassTransit log without requiring a web client license or plug-in. Configuration instructions follow below in the Description section.

For information about configuring MassTransit Server 7 for use with Directory Services, please refer to: Active Directory page of the MassTransit 7 documentation.

Description:

This article explains how you can enable Directory Services, enable the Log Viewer for Active Directory contacts, create a contact with Active Directory authentication, and how users can log on via MTWeb and FTP.

This article assumes that MassTransit 5.1  or higher is installed and that MassTransit Web (MTWeb) configuration is already completed if using web client accounts and/or enabling an Active Directory log viewing group. See the Related Documents section for links to the Installation and Web configuration documents.

Be aware that MassTransit’s Directory Services integration currently supports Active Directory on a supported Windows server platform. Currently, MassTransit can only integrate with a single domain.

Enabling Directory Services

NOTE: All lines beginning with “%%” in the MassTransitEngine.cfg file are considered commented and therefore ignored. You must uncomment all lines mentioned in the steps below.

  1. Open the MassTransitEngine.cfg file located in the root MassTransit directory. The default location on Windows is C:\Program Files\Group Logic\MassTransit Server 5 for MassTransit 5.1.x and C:\Program Files\Group Logic\MassTransit Server 6 for MassTransit 6.0 and later; the default location on Mac OS X is \Applications\MassTransit Server 5 folder for MassTransit 5.1.x and \Applications\MassTransit Server 6 folder for MassTransit 6.0 and later.
  2. Go to the Directory Services section of the file and set the DIRECTORY_SERVICES_ENABLED setting to TRUE. Then, enter all the values for all of the flags.
    NOTE: On Windows the LDAP_BIND_DN and LDAP_BIND_PASSWORD flags may be left blank to indicate that MassTransit is to bind to the LDAP server as the currently logged in user. The machine must be bound to the domain and the MassTransit service must be running as the user MassTransit is to use to bind to the LDAP server. To configure the MassTransit service open the Services window, highlight the service named “MassTransit”, right click and select Properties, go to the Log On tab, select the “This account” option, enter the account name and password, and select OK.

  1. Once you’ve completed the above steps, you will need to restart the MassTransit Engine for the changes to take effect.

NOTE: MassTransit 6.0 implements the automatic Active Directory account management feature that allows setting up MassTransit contacts, forwarding privileges and so on automatically based on existing Active Directory groups. For more information about this feature see the INFO: Automatic Active Directory Account Management With MassTransit article.

Configuring MassTransit To Authenticate Against LDAP Organizational Units

The directory services settings located within the MassTransitEngine.cfg configuration file are configured to search the Active Directory “Users” folder by default; however, they may be modified to search Organizational Units (OUs) instead.

This may be an optimal configuration for administrators that wish to create a “MassTransit Users” organizational unit, without impacting the standard “Users” folder.

The following is a procedure to make the necessary modifications:

  1. Open the MassTransitEngine.cfg configuration file.
  2. Locate the configuration option: LDAP_SEARCH_BASE=CN=
  3. Adjust the LDAP_SEARCH_BASE setting to reflect your custom Organizational Unit. For example:LDAP_SEARCH_BASE=OU=Your_Organizational_Unit,DC=Your_Domain,DC=COM

NOTE: This configuration example reflects an Organizational Unit that resides within the root of the LDAP directory structure. If the Organizational Unit resides elsewhere, the OU= parameter will need to reflect the exact location of the OU within the tree.

The search base may actually contain any part of the directory tree. In such configurations, the AD Administrator must specify the Fully Qualified Domain Name (FQDN) without the DC= connection strings. For example:

LDAP_SEARCH_BASE=CN=Development,OU=MassTransit

Enabling the Log Viewer

  1. If you would like to enable the MassTransit Log Viewer for an authorized group, open the mtweb.ini file located in the MTWeb directory. On Windows, the default folder is C:\Program Files\Group Logic\MassTransit Server 5\MTWeb for MassTransit 5.1.x and C:\Program Files\Group Logic\MassTransit Server 6\MTWeb for MassTransit 6.0 and later. On the Mac, the default folder is /Applications/MassTransit Server 5 Folder/MTWeb for MassTransit 5.1.x  and /Applications/MassTransit Server 6 Folder/MTWeb for MassTransit 6.0 and later.
  2. Go to the Application section of the file and follow the instructions for configuring the AUTHENTICATE_METHODS and AUTHORIZED_LOG_VIEWING_GROUP flags.NOTE: The order of the AUTHENTICATE_METHODS flag can be reversed. If the original order of the flags is used (AUTHENTICATE_METHODS = AuthMethod_SOAP,AuthMethod_LogViewingGroup), then a web client that is both a MassTransit contact with Active Directory authentication and a member of the authorized log viewing group will be navigated to the MassTransit plug-in once authenticated. The only way that user will be able to view the Log is if privileges are given to that individual user via the MassTransit Administrator when the account is created or edited; then the Log tab will be present. If the current order of the flags is reversed (AUTHENTICATE_METHODS = AuthMethod_LogViewingGroup,AuthMethod_SOAP), then the user will be navigated to the Log Viewer, but will not be navigated to the plug-in for file transfer. The default approach is recommended.
  3. Once you’ve completed the above steps, you will need to restart IIS or Apache and the MassTransit Engine for the changes to take effect.

Creating a Contact with Active Directory Authentication

  1. Via the MassTransit Administrator, Add either a Web Client or Application Client Contact.
  2. In the Authentication section of the General tab, select the Active Directory option.
  3. In the Account field, enter the user logon name in either of the following formats: username@domain.com or DOMAIN\username.
  4. Select the Search button; once the user is found in the directory, a green light will appear, and the contact can now be saved.
  5. Once a contact configured to use Active Directory authentication has been saved, the corresponding contact information from Active Directory will populate to the Contact Information fields on the General Tab. All of the populated information from Active Directory is read-only.

Logging on via MTWeb

  1. Via a supported browser, log on to the configured server.
  2. Enter your Active Directory logon name in either of the following formats: user name or DOMAIN\username.
  3. Enter your Active Directory password.

Logging on via FTP

  1. Via a supported browser or stand-alone FTP client, log on to the configured server.
  2. Enter your Active Directory logon name in either of the following formats: user name or DOMAIN\username.
  3. Enter your Active Directory password.

Related Article: