LDAP:: In a bind? LDAP can help! – Part 2

This post is part 2 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 the bind portion of LDAP.

What is a “bind”?

Not to be confused with BIND (the DNS server), bind in LDAP is essentially authenticating to the LDAP server to allow access to query for schema attributes. You “bind” to the server and start LDAP-ing.

Binds can occur in one of three main ways.

1. Anonymous

This type of bind is, as the name suggests, extremely insecure. Anonymous binds allow everyone and anyone who has the LDAP server information to query for users, groups, etc. There is no username or password needed. While this is much easier to set up and likely much faster (since we don’t have to ask any questions/give any answers), it’s also not recommended. In fact, many vendors, including Microsoft Active Directory and RedHat, disable anonymous binds by default.

2. Simple

Simple binds are more secure than anonymous binds in that the require a valid user in LDAP with read-only permissions, as well as a password. However, simple binds still aren’t *that* secure, as the password is passed over the wire. In plain text.



With simple binds, it’s possible to use SSL to encrypt the bind to prevent that. In the example below, I connected to my LDAP server over SSL on port 636 using ldp.exe:


My Windows 2008R2 LDAP server supports GSSAPI, GSS-SPNEGO, EXTERNAL and DIGEST-MD5 for SASL. Even though we’re doing simple bind, we still encrypt using the strongest available enctype possible on the LDAP server. In this case, we end up using AES:


And a packet trace shows no LDAP packets – only TLSv1:


Some caveats:

  • Setting up LDAP over SSL on your LDAP server isn’t  the most intuitive thing in the world, but it’s not hard. For Windows, use the following links:

LDAP over SSL Certificate

Using ldp to test connectivity

  • When you use LDAP over SSL, good luck troubleshooting LDAP queries via packet trace. They’re all encrypted now.
  • LDAP clients must have the certs installed as well.


Simple Authentication and Security Layer (SASL) is a security mechanism that allows a variety of different encryption types to be used without the need for setting up certificate services on a LDAP server. It splits the authentication mechanism out and allows more integrated mechanisms to be used. A list of these can be found on the SASL wiki page.

Using our existing setup as an example, I can leverage Kerberos to bind to my LDAP server rather than SSL. Ldp.exe is a great tool to use for this, as I can control how my binds occur. Be on the look out for future posts on that tool…

When I bind via SASL, I see LDAP packets, but my bind doesn’t come across with a username/password. Instead, I am able to use Kerberos to bind. I didn’t even need to provide a username/password at all!

The following query was done from a cluster running clustered Data ONTAP 8.2.3:


In the trace, we’re doing AES-256 (strongest enctype available) to bind using SPNEGO (SPN negotiation). To do this, you would need a SPN with the LDAP server information available.

For example:

C:\>setspn /Q ldap/2k8-dc-1.domain.win2k8.netapp.com
Checking domain DC=domain,DC=win2k8,DC=netapp,DC=com
CN=2K8-DC-1,OU=Domain Controllers,DC=domain,DC=win2k8,DC=netapp,DC=com
Existing SPN found!

Additionally, you’d need a LDAP SRV record in DNS for the specified LDAP server. In this case, I use “domain.win2k8.netapp.com” as my LDAP server.

Default Server: UnKnown
Address: ::1
> set type=all
> _ldap._tcp.dc._msdcs.domain.win2k8.netapp.com
Server: UnKnown
Address: ::1
_ldap._tcp.dc._msdcs.domain.win2k8.netapp.com SRV service location:
 priority = 0
 weight = 100
 port = 389
 svr hostname = 2k8-dc-1.domain.win2k8.netapp.com
2k8-dc-1.domain.win2k8.netapp.com internet address =
2k8-dc-1.domain.win2k8.netapp.com AAAA IPv6 address = fd20:8b1e:b255:8599:5457:61d9:fc87:423f

As luck would have it (ok, design), Microsoft Active Directory is perfect for UNIX based LDAP because it already includes things like SRV records, SPNs, etc. The only time things get hard is when you have to get more customized with the configuration.

You can also do many of the same things with any LDAP server that supports the RFC-2307, RFC-2251, etc. standards.

What can be used to bind?

For authenticated binds, the options for what can be used for binding to LDAP depend on the client. For details, contact the owner of the LDAP client or the docs.

Some of the options include:

  • Name in LDAP DN format. (ie, CN=ldapuser,OU=Users,DC=domain,DC=com)
  • Simple user name. (ie, ldapuser)
  • User principal name (UPN, ie ldapuser@domain.com)
  • Service principal name. (SPN, ie root/fqdn.domain.com)
  • Blank user name. (anonymous binds or binds that negotiate protocols via Kerberos/DNS)
  • CIFS/SMB Machine account. (Often in storage vendors where CIFS is also present)

If using a user to bind with simple or SASL, then the user has to have readonly access to the LDAP schema.

Troubleshooting binds

Troubleshooting binds should be pretty straightforward – you are essentially troubleshooting a login.

The following things should be considered when dealing with binds that are not working properly:

  • Is the LDAP client connecting to the server? (check network, ports, IP, DNS, etc.)
  • Is the LDAP server/hostname correct?
  • Is the bind level correct? Does the client configuration for bind level match what the server supports? (SSL? SASL?)
  • If using SSL, is the LDAP port configuration correct? (Port 389 for LDAP, port 636 for SSL, port 3268 for Active Directory Global Catalog searches)
  • Is the bind user correct? The bind password?
  • If intending to use Kerberos for binds, is there a SPN configured? Are there forward (A/AAAA) and reverse (PTR) DNS records for the LDAP server/domain?

Some tools that come in handy for troubleshooting LDAP:

  • Ping
  • Telnet (to check for ports)
  • Netstat (to check for ports)
  • Nslookup/dig
  • Ldp.exe
  • Ldapsearch
  • Wireshark/tcpdump (my personal favorite)
  • Various logs (Event viewer in MS, /var/log in Linux) – try debug level!

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?

TECH::Using PowerShell to back up and restore CIFS shares/NFS exports in NetApp’s clustered Data ONTAP

NOTE: This post covers DR for NAS objects prior to 8.3.1. After 8.3.1, use the new SVM DR functionality if possible.


NetApp’s Data ONTAP operating in 7-mode kept all relevant configuration files in its root volume under /etc. These files get read at boot and are used to set up the filer. This included stuff like DNS configuration (resolv.conf), name service switches (nsswitch.conf), initial config (rc file), hosts and other various configuration files.

Another file that is stored in /etc in 7-mode is the file that builds the filer’s CIFS shares each time it is booted – cifsconfig_share.cfg.

This file is essentially a list of CIFS share and access commands that gets sourced each time the system boots. This is what one of those files looks like in 7-mode:

#Generated automatically by cifs commands
cifs shares -add "ETC$" "/etc" -comment "Remote Administration"
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home" -comment "Default Share"
cifs access "HOME" S-NONE "nosd"
cifs shares -add "C$" "/" -comment "Remote Administration"
cifs access "C$" S-1-5-32-544 Full Control
cifs shares -add "CIFS" "/vol/cifs" -comment "CIFS"
cifs access "CIFS" S-NONE "nosd"
cifs shares -add "mixed" "/vol/mixed" -comment ""
cifs access "mixed" S-NONE "nosd"

7mode> cifs shares
Name Mount Point      Description
---- -----------      -----------
ETC$ /etc             Remote Administration
                 BUILTIN\Administrators / Full Control
HOME /vol/vol0/home   Default Share
                 everyone / Full Control
C$ /                  Remote Administration
                 BUILTIN\Administrators / Full Control
CIFS /vol/cifs        CIFS
                 everyone / Full Control
mixed /vol/mixed
                 everyone / Full Control

One benefit of this file in 7-mode was the ability to copy this file off somewhere to back up and possibly restore the shares at a later date, or even retrieve the file from snapshot.

However, with the newer clustered Data ONTAP, the concept of flat files is gone. Everything gets stored in a replicated database, which helps the cluster act like a cluster. I cover that in some detail in a previous post on DataCenterDude.com, NetApp cDOT, RDB, & Epsilon.

Additionally, in clustered Data ONTAP, if a CIFS server gets deleted (such as when removing it from the domain/re-adding it), the CIFS shares get blown away and would need to get re-created one by one.

So what do the people who relied on the old 7-mode CIFS share files do?

Script it out, of course! For more information, including where to find pre-written scripts, see the post on DataCenterDude.com!

Requires powershell module for Data ONTAP, which can be found here: http://mysupport.netapp.com/NOW/download/tools/powershell_toolkit/download.shtml


Recently, a consultant named Scott Harney was inspired by the CIFS share script and not only made some improvements to it, but also created one for NFS exports and rules!

Check it out at his blog:



UPDATE #2 (7/6/15):

Tested the scripts with both 8.2.4 and 8.3.1. Had to work out a few kinks/make some improvements. There is an issue in 8.3.1 with Add-NcCifsShare.

The following changes were made:

  • Tested with 8.2.4 and 8.3.1 cDOT releases
  • Change Import-Module to generic “DataONTAP” to avoid path issues
  • Added link to DataONTAP PS module download in comments
  • Changed PS commands to replace “-Name” with “-Share”
  • Changed output file of ACLs to $aclFile (was $shareFile)

These changes are up on the github repository now. Feel free to notify me if anything else is broken or needs improvement!


If you’re looking for a way to backup Snapmirror schedules, see this link: http://mysupport.netapp.com/NOW/download/tools/smtk/

TECH::Spring cleaning for your NAS environment

The other day, I was on a customer call, helping with some NAS/netgroup configuration. We were running some tests connecting to a LDAP server to fetch netgroups when I noticed that a netgroup of 100 hosts only returned four IP addresses. FOUR!

There wasn’t anything broken from the storage side. Instead, it was the netgroup – of the 100 hosts, only 4 still existed in DNS.


April mis-configurations bring disrupted summer vacations

Every spring, I like to clean out the garage, clean the grill grates, and eventually, spray off the thick coat of North Carolina pollen that has caked itself on. If I were to let this stuff go all year, I’d probably be featured on some reality show like Hoarders.

The same mentality could be applied to your NAS environment maintenance.

  • Removed hosts from the network? Remove them from DNS.
  • Removed hosts from DNS? Remove them from netgroups.
  • Removed netgroups? Remove them from export policies and rules.
  • Changed IP addresses? Make sure those changes are applied everywhere.

If you don’t keep up with your NAS environment, you might be getting calls from your users and/or customers at hours or times you don’t appreciate. Once, on my on-call weekend when I was in support, I had to work a case at 3AM. At the beach. In a hotel parking lot. Stealing wi-fi.

The root cause? Someone mis-configured something.

The fact that I was at the beach and had to be in a hotel parking lot stealing wi-fi was due to my own poor planning. Everyone loses!

Centralize and organize

Some environments still use flat files for hosts, netgroups, etc. While that’s ok, you should start considering consolidating those files into a centralized name service like LDAP, NIS, DNS, etc. After all, it’s a lot easier to make a change on one server than on 600.

If you move away from flat files, you make your life easier, bottom line. And you make your spring cleaning efforts that much more bearable.

What else can you do?

Along with spring cleaning/regular maintenance of your name services, be sure to follow best practices for your NAS environment. For clustered Data ONTAP, I’ve recently published an update to TR-4379: Name Service Best Practices, which covers best practices for many scenarios. For example… Using short hostnames? Don’t. Use FQDNs whenever possible. Shortnames force the DNS client to figure out the DNS zone, which add latency to requests.

Also, pro-tip: If you’re on-call, try to remember not to also be on vacation.