TECH::Register for #NetAppInsight 2015 today!

Every year, NetApp holds a technical conference for storage and data management professionals called NetApp Insight. For the past 2 years, I’ve presented at these conferences for my technical field (NFS/multiprotocol). This year, I will be presenting again in Las Vegas and Berlin!

(If you register by July 31, you get a “super saver” discount.)

What sessions am I doing?

This year, I’ll be focusing solely on multiprotocol in clustered Data ONTAP in an attempt to help people better understand the myriad questions surrounding the use SMB and NFS on the same unified data storage. I’ll be doing a session on general multiprotocol best practices and operation called:

1884 –  Unlocking the Mysteries of Multiprotocol NAS in Data ONTAP

Having trouble understanding multiprotocol? Can’t figure out the difference between authentication and authorization? Do you think a name mapping rule is something doctors provide to new parents at the hospital? Wondering what a “CIFS/SMB” and “NFS” is anyway? This session can help! We cover all things NAS in clustered Data ONTAP, from the basics to the best practices, and try to help make multiprotocol a little clearer for storage administrators.

For a deeper understanding of the inner workings of authentication in clustered Data ONTAP (which is integral to multiprotocol), I’ll be doing a session called:

1881 –  Authentication in Clustered Data ONTAP: SecD Deep Dive

Authentication in clustered Data ONTAP uses the security daemon (SecD) for connectivity to external dependencies for NAS protocols such as Active Directory, LDAP, NIS and DNS. This session will cover how SecD works in clustered Data ONTAP 8.3 and beyond, as well as how to troubleshoot issues and what kind of statistics are available for SecD and external name services.

In addition, I will be offering a Hands On Lab for Multiprotocol, where you can play with LDAP and NFS/SMB access on clustered Data ONTAP in real time!

Schedules will be available soon, so sign up early to ensure you get a spot in one of my sessions and the lab!

Check back here periodically for any updates and links to the sessions.

LDAP::LDAP Servers and Clients – Part 5

UPDATE: I realized today that I wrote this same topic twice, in two different posts. This one should be considered the combined effort, but may read a bit like a blog Frankenstein. Original of the other one remains up here:

This post is part 5 of the new LDAP series I’ve started to help people become more aware of what LDAP is and how it works.

Part one was posted here:

What the heck is an LDAP anyway?

This post will focus on LDAP servers and clients.

Servers vs clients

In the animal kingdom, you will often see symbotic relationships, such as the alleged relationship between crocodiles and the plover bird, which eats dead stuff from the croc’s teeth.


The LDAP client/server relationship is also symbiotic. The server needs the client to ask it questions and the client needs the server to feed it information.

If nature isn’t your thing, there’s always the Spider-Man/Venom symbiotic relationship:


In the case of LDAP, a client will be asking for things like usernames, home directory locations, group memberships, etc. The server would be responsible for delivering that information.

LDAP isn’t unlike other protocols, such as HTTP, NFS, etc. There is a client and server relationship. And just like any successful relationship, there needs to be someone talking and someone listening.

I have a two year old son. He talks, but most of it is just practice for him. He’ll say things like “dada, bird truck.” And I’ll say “Bird? Truck? Cool!” It’s mostly a one-sided conversation where I essentially ACK his SYNs. (I need to get out more)

Sometimes, it’s “dada read book.” And I comply.

LDAP client/server conversations aren’t much different. The client is my two year old. The LDAP server is me.

“LDAP, find user information”

“User information? Cool! Here ya go!”

At its very base, LDAP conversations are nothing more than TCP SYNs and ACKs. So, when configuring or troubleshooting, they should be treated as such.

Where things get muddled is when you start to consider what it takes for a client/server relationship to be successful. It’s not a good idea to leave the channels of communication wide open for everyone in the world to see, so there are some rules we have to follow when clients want to talk to servers.

Client/Server configuration

LDAP clients can be anything running software that can query LDAP via RFC-2307 standards. Windows, Linux, storage system OSes, etc can all act as clients. Some operating systems contain built-in LDAP functionality (such as Windows) that doesn’t require you to install anything special. Some storage systems, such as NetApp’s clustered Data ONTAP, fully support LDAP that adheres to the RFC-2307 standard. For more information, see TR-4073: Secure Unified Authentication.

Basic network information.

Remember, at its base, it’s a simple TCP conversation.

  • LDAP server names, URI or IP addresses (is the server in DNS? Are there SRV records for LDAP?)
  • LDAP port (default ports are 389 for LDAP, 636 for LDAP over SSL, 3268 for Global Catalog; did you change the server port?)
  • Can the client talk to the server (routing?)

Before a client can initiate a conversation with a server, it has to be configured with information about that server. The configuration will follow the basics of the OSI model, starting at the first few layers of the stack to initiate a TCP conversation with the server.

Common LDAP clients

LDAP clients also tend to adhere to the same standards as the servers. Why? Because it makes sense. Clients can stand alone from an operating system, but some OSes integrate LDAP into their configuration by default. Windows is an example of this because of how integral LDAP is to Active Directory.

Other clients include (but are certainly not limited to):

  • SSSD
  • OpenLDAP

Hopefully the information in this post has helped clear up any confusion on LDAP clients and servers.

Some LDAP servers will even allow you to make modifications to the port it listens on for LDAP communication. This is to help secure LDAP servers by not leveraging well known ports. With common LDAP servers such as Active Directory, however, it’s difficult to use different ports from the common ones. When configuring the clients, the LDAP server configuration always needs to be reviewed.

After we get past the TCP connection, we spend our time in the application layer of the OSI model.


Bind/Login information.

First we have to worry about authenticating to the LDAP server. This is also known as binding. The level of authentication will depend on what the server has been set to allow. The lowest possible authentication level is “anonymous,” but no modern LDAP server allows anonymous binds by default. Generally, a read-only account on the LDAP server is required to authenticate to a server to issue LDAP queries.

The necessary bind information is included in the client configuration. For the most secure configuration, using a ticket or key based authentication system is preferred over using passwords.

LDAP Search Information

After a bind takes place, the queries are performed. The nature of the queries will depend on the client configuration. What schema are we using? What information do we need? Have we configured the client to make sure to try LDAP for information at all times (via nsswitch.conf configuration)? Did we tell the client where to start looking for information on the LDAP server by providing the base DN?

This tells the client where to start looking for information in the LDAP server.The format for this information is Distinguished Names (DNs), which I cover in part 4. You can set a base DN and then specific DNs for users, groups, netgroups, etc. You can even specify multiple locations to search. The idea here is to filter our searches to speed things up for the clients.

Fun fact: Apple auto-corrects DNs to DNS. Not cool, Apple. Not cool.

Once the LDAP client has the necessary information, it should unbind – we don’t want to stay logged in indefinitely. That’s a resource hog.


LDAP schema information

I cover schemas in detail on part 3. Many clients know about the default schemas LDAP uses, such as RFC-2307, RFC-2307bis, etc. In most cases, the schemas on the server will not stray from that. But in some instances, such as through manual intervention or 3rd party tools like Dell Vintela (also known as Centrify, Quest, etc), there may be need to make adjustments. This can be done on the client. This allows the client to ask for the right information from the server, which then allows the server to find the information and respond to the client.

Client-specific options

Many clients offer specific options like caching of users/groups, credentials, Kerberos configuration, etc. These are generally optional, but should be looked into on a per-client vendor basis.

Sample client configuration

The following is an example of what a clustered Data ONTAP LDAP client would look like:

cluster::*> ldap client show -client-config DOMAIN

                                 Vserver: NAS
               Client Configuration Name: DOMAIN
                        LDAP Server List:
                 Active Directory Domain:
       Preferred Active Directory Servers: -
Bind Using the Vserver's CIFS Credentials: false
                          Schema Template: WinMap
                         LDAP Server Port: 389
                      Query Timeout (sec): 3
        Minimum Bind Authentication Level: sasl
                           Bind DN (User): ldapuser
                                  Base DN: dc=domain,dc=win2k8,dc=netapp,dc=com
                        Base Search Scope: subtree
                                  User DN: cn=users,dc=domain,dc=win2k8,dc=netapp,dc=com
                        User Search Scope: subtree
                                 Group DN: cn=users,dc=domain,dc=win2k8,dc=netapp,dc=com
                       Group Search Scope: subtree
                              Netgroup DN: -
                    Netgroup Search Scope: subtree
               Vserver Owns Configuration: true
      Use start-tls Over LDAP Connections: false
 Allow SSL for the TLS Handshake Protocol: -
           Enable Netgroup-By-Host Lookup: true
                      Netgroup-By-Host DN: -
                   Netgroup-By-Host Scope: subtree

This is what my client configuration running SSSD looks like:

# cat /etc/sssd/sssd.conf
cache_credentials = True
case_sensitive = False
config_file_version = 2
services = nss, pam
domains = DOMAIN
debug_level = 7
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
filter_groups = root
id_provider = ldap
auth_provider = krb5
case_sensitive = false
chpass_provider = krb5
cache_credentials = false
ldap_uri = _srv_,ldap://
ldap_search_base = dc=domain,dc=win2k8,dc=netapp,dc=com
ldap_schema = rfc2307
ldap_sasl_mech = GSSAPI
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_group_member = memberUid
ldap_group_name = cn
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_user_search_base = cn=Users,dc=domain,dc=win2k8,dc=netapp,dc=com
ldap_group_search_base = cn=Users,dc=domain,dc=win2k8,dc=netapp,dc=com
ldap_sasl_authid = root/
krb5_server =
krb5_kpasswd =


If you want somewhere for the clients to ask for information, you need a server. The server needs to have a valid RFC-2307 schema to contain the necessary LDAP objects. If you’re doing UNIX-based LDAP and want to use Microsoft Active Directory to serve UNIX-based authentication, then you’d need to ensure the server has UNIX attributes in the schema. While Microsoft Active Directory runs on a LDAP backend, it’s not true UNIX-based LDAP server until you extend the schema. I talk a bit about this in my blog post on IDMU.

As mentioned in the client section, you need a bunch of information to configure clients. The server is where this information comes from. Here’s the stuff you need to check on the server to ensure you configure your clients correctly:

  • Server network info (IP address, hostname, DNS entries, SRV records, LDAP server ports, etc.)
  • Supported bind level (use the strongest available, if possible)
  • Valid bind user or SPN
  • DN information
  • Schema type/attributes

LDAP servers can host tons of information. UNIX user creds, Windows creds, netgroups, IP addresses, SPNs, name mapping rules…. It just depends on what the clients support that determines what you can use.

Common LDAP servers

LDAP servers all tend to adhere to a common set of standards as defined by IETF. This is to ensure a wide range of support for clients. Some of the more common LDAP servers include (but are not limited to):

  • Active Directory
  • OpenLDAP
  • RedHat Directory Server/389 Directory Server
  • Apple Open Directory
  • Oracle Internet Directory
  • ApacheDS

LDAP Referrals

If you are using multiple LDAP servers and a client is not able to find an object in the specified LDAP server’s domain, it may attempt to use an LDAP referral to look in the other servers. Essentially, it takes information in the LDAP server about other servers we know about and attempts to connect to them via LDAP URI until it either a) finds the object or b) runs out of servers to try. This can happen in both Windows and non-Windows LDAP servers. Some LDAP clients do not support “referral chasing,” so it’s important to know if this is happening in your environment and if your client is able to chase referrals.

Global Catalog Searches

In Active Directory, it is possible to store a copy of attributes from multiple domains in a forest on local domain controllers acting as Global Catalog servers. By default, UNIX attributes don’t get replicated to the Global Catalog, but you can change that behavior as needed. I cover how to do this in TR-4073. If you need to query multiple domains in the same forest and want to avoid LDAP referrals, you can simply replicate the necessary attributes and change the LDAP port to 3268 to let the servers know to use the Global Catalog instead!

My environment

In my environment, I use Active Directory LDAP with Identity Management. But I’ve been known to use OpenLDAP and RedHat Directory Services. Both are perfectly valid to use. However, if you’re intent on doing multiprotocol NAS (CIFS/SMB and NFS), I strongly suggest using Microsoft Active Directory for authentication for UNIX and Windows users. Makes life infinitely easier.

If you are already using Linux-based LDAP, that’s fine. If possible, try to ensure the UNIX user names (uid LDAP attribute) match the Windows user names (sAMAccount attribute). That way, if you are using multiprotocol NAS, you don’t have to worry about name mapping.

If you want to see anything added to this post regarding LDAP servers and clients, feel free to comment or follow me on Twitter @NFSDudeAbides!


For more detailed information on LDAP configuration (particularly with NetApp clustered Data ONTAP), see TR-4073: Secure Unified Authentication.

Also, stay tuned for more in the series of LDAP basics on this blog!

Links to other sections can be found on the first post in this series:

What the heck is an LDAP anyway?

VMWORLD::Meet the engineer at NetApp’s booth!

I’ll be going to my first VMWorld in San Francisco this year and I have no idea what to expect. But what I do know is that I’m going to be a part of the “Meet the Engineer” portion of the conference. These meetings are chances for customers to come get to know us and find out more about NetApp goodness, such as clustered Data ONTAP!


If you want to come meet me or one of my colleagues, feel free to sign up here:

Engineers include:

Topics include:

Not only do you get the benefit of meeting me, but you also get either a portable USB phone charger (these are friggin awesome, btw), USB charger cable and/or NetApp laptop sticker.

Additionally, if you sign up for a meeting, you can attend our “Hall Crawl,” where we’ll be serving craft beer at the NetApp booth from 4-6:30 PM on Tuesday, Sept. 1.

Hope to see you there!

TECH::TR-4379 Name Services Best Practices in clustered Data ONTAP updated for 8.3.1!

It’s time for new technical report updates!

Since clustered Data ONTAP 8.3.1 is now available, we are publishing our 8.3.1 updates to our docs.


TR-4379: Name Services Best Practices covers a wide range of considerations when using external name services like LDAP, DNS and NIS with your clustered Data ONTAP storage system. External name services are critical to NAS environments, as they help control identity management, Kerberos authentication, hostname resolution, netgroups and export policy rule access.

What’s new in TR-4379?

  • Dynamic DNS support information for 8.3.1
  • Clarification and updates on existing best practices
  • Improved information on name server best practices
  • Upgrade considerations

Where can I find it?

Technical reports can be found a variety of ways. Google search works, as does looking in the NetApp library. I cover how to be better at NetApp documentation in a separate blog post.

To make it super easy, just follow this link:

TR-4379: Name Services Best Practices

TECH::July 2015 update to TR-4067 (the NetApp NFS best practice manifesto)

It’s time for new technical report updates!

Since clustered Data ONTAP 8.3.1 is now available, we are publishing our 8.3.1 updates to our docs. The first one in the list for me was TR-4073: Secure Unified Authentication. Next up, TR-4067: NFS Best Practice and Implementation Guide!

What is NFS?

NFS stands for “Network File System.” There are tons of docs out there on the subject, but essentially, it’s a way to access a central storage system via network accessible shares, generally running on Linux clients. NFS itself is a standard protocol, defined by the Internet Engineering Task Force (IETF) standards.

What is Clustered Data ONTAP?

Clustered Data ONTAP is NetApp’s storage operating system that allows a subset of physical hardware to act as a single entity for data access.

What’s new in TR-4067?

There wasn’t a ton of stuff that changed. The new updates to the doc include:

  • Improved navigation for best practices
  • cDOT 8.3.1 changes
  • pNFS document links

Where can I find it?

Technical reports can be found a variety of ways. Google search works, as does looking in the NetApp library. I cover how to be better at NetApp documentation in a separate blog post.

To make it super easy, just follow this link:

TR-4067: NFS Best Practice and Implementation Guide

Be on the look out for other new TR updates!

TECH::July 2015 update to TR-4073 (the NetApp NFS Kerberos/LDAP manifesto)

It’s time for new technical report updates!


Since clustered Data ONTAP 8.3.1 is now available, we are publishing our 8.3.1 updates to our docs. The first one in the list for me was TR-4073: Secure Unified Authentication.

What is Secure Unified Authentication?

Secure Unified Authentication is a solution-based methodology to provide secure (via Kerberos) unified (via central LDAP servers for identity management) authentication for enterprise IT environments.

Security is more important than ever, so using a ticket-based auth process instead of over-the-wire passwords is one way to ensure you have protected your business assets. With AES-256 encryption, you are using the strongest available enctype for Kerberos.

Ease of management is also critical to an ever changing IT landscape. LDAP for Identity Management makes user account management and NAS permissioning easier.

What’s new?

The new updates to the doc include:

  • Moving lengthy config steps to the end of the document to avoid doc clutter
  • Moving scripts from the doc to a github repository for open source contribution
  • Better organization/navigation of crucial best practices
  • Documentation of new 8.3.1 functionality (HINT: not a ton changed for Kerberos/LDAP)
  • Improved On-Box DNS documentation
  • ESXi 6.0 Kerberos Configuration steps
  • Improved LDAP multiprotocol asymmetric name mapping information
  • Improved SecD troubleshooting information
  • LDAP search optimization recommendations
  • Mapping of 7-Mode LDAP attributes to clustered Data ONTAP attributes
  • Using hostnames for LDAP servers via SRV records
  • LDAP bind support information

Where can I find it?

Technical reports can be found a variety of ways. Google search works, as does looking in the NetApp library. I cover how to be better at NetApp documentation in a separate blog post.

To make it super easy, just follow this link:

TR-4073: Secure Unified Authentication

Be on the look out for other new TR updates!

Why Is the Internet Broken: Greatest Hits

When I started this site back in October of 2014, it was mainly to drive traffic to my NetApp Insight sessions -and it worked.

(By the way… stay tuned for a blog on this year’s new Insight sessions by yours truly. Now with more lab!)

As I continued writing, my goal was to keep creating content – don’t be the guy who just shows up during conference season.


So far, so good.

But since I create so much content, it gets hard to find for new visitors to this site, The WordPress archives/table of contents is lacking. So, what I’ve done is create my own table of contents of the top 5 most visited posts.

Top 5 Blogs (by number of visits)

TECH::Using NFS with Docker – Where does it fit in?

SMB1 Vulnerabilities: How do they affect NetApp’s Data ONTAP?

TECH::Become a clustered Data ONTAP CLI Ninja

ONTAP 9.1 is now generally available (GA)!

NetApp FlexGroup: An evolution of NAS


I also used to write for on occasion.

To read those, go to this link:

My DataCenterDude stuff

How else do I find stuff?

You can also search on the site or click through the archives, if you choose. Or, subscribe to the RSS feed. If you have questions or want to see something changed or added to the site, follow me on Twitter @NFSDudeAbides or comment on one of the posts here!

You can also email me at