Manual Xsan profile changes

When adding clients to an Xsan, the normal process is to install an Xsan profile on the client which tells the client how to talk to the Open Directory.  Then the Xsan configuration is pulled down from Open Directory and the client is able to connect.  Occasionally we need to modify that profile.  Here are 2 ways we have changed the profile in certain circumstances.

In several of our Xsan environments we have clients that connect to 2 sans (future post coming).  One of the keys to this is sharing the same auth_secret between the 2 sans. We are still testing how to update the auth_secret in ldap, so the default profile can create the appropriate connections.  Until we have that sorted, we are using a modified profile for the connections.

To start, export a profile with xsanctl from an MDC sudo xsanctl exportClientProfile --path ~/Desktop/

Then use your favorite text editor (I prefer BBEdit) to open the .mobileconfig file.

Find the lines

<key>sanAuthMethod</key>
<string>auth_secret</string>

And add these two lines below

<key>sharedSecret</key>
<string><.auth_secret here></string>

To get the value for <.auth_secret here> we can run sudo cat /Library/Preferences/Xsan/.auth_secret

Now our mobileconfig file should have a section like

<key>sanAuthMethod</key>
<string>auth_secret</string>
<key>sharedSecret</key>
<string>BnCH5QkGyS2oUn9CUcdPNCqyxR6AAFxusFeGtMF5dzhWJdWg1nZ6BPgnH32gWLrX</string>

Another change we try to avoid, but comes in useful is to change the configuration URLs.  By default the client uses those URLs to talk to the Open Directory LDAP and get the rest of the configuration from there.  Occasionally we have had trouble with Open Directory not being reachable.  Often the problem is DNS or network related, but sometimes you can’t fix it (or at least not right away).

We can tell the client where the MDCs are directly by changing the config profile.

Find the lines 

<key>sanConfigURLs</key>
<array>
 <string>ldaps://xsantest-mdc.testsan.priv:389</string>
 <string>ldaps://xsantest-bmdc.testsan.priv:389</string>
</array>

And replace them with something like this where the IPs are the metadata network IPs of your MDCs.

<key>fsnameservers</key>
<array>
 <string>10.0.0.1</string>
 <string>10.0.0.2</string>
</array>

Now when setting up a client, it won’t try to talk to Open Directory, it will connect to the MDCs directly using the auth_secret we hard coded into the profile.

 

Leaving the auth_secret in plain text on the clients isn’t ideal, but we feel there can be enough other protections on the Xsan and data.  With the auth secret a client can connect to the MDCs and find the configuration. With that it could be possible to mount the san on some other client. There are a few other security measures that can prevent this from happening. The fibre switch that everything runs through can be/should be set up with zoning so that only authorized HBAs can connect to the san LUNs. The volume can be set up with ACLs to control access to the data once the volume is connected.