May 2016 update to TR-4073 (the NetApp NFS Kerberos/LDAP manifesto)

It’s time for new technical report updates!

koolaid

Since clustered Data ONTAP 8.3.2 is now available, we are publishing our 8.3.2 updates to our docs. I finally got the updates added to 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?

  • PowerShell alternatives to LDIFDE queries
  • Extended GIDs best practices
  • Improved asymmetric name mapping support in LDAP
  • Expanding all hosts in a netgroup information
  • Vserver security command examples and information (fsecurity command parity)
  • Improved RFC-2307bis informati0n
  • Bind DN examples
  • LDAP terminology

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. I also have a yet-unfinished series on LDAP here:

LDAP::What the heck is an LDAP anyway? – Part 1: Intro

To make it super easy, just follow this link:

TR-4073: Secure Unified Authentication

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:

https://whyistheinternetbroken.wordpress.com/2015/06/05/ldapldap-servers-and-clients-and-bears-oh-my-part-5/

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.

crocodileplover

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:

spider-symbiote

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.

osi-network-layer-cats

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.

unbind

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: 10.228.225.120
                 Active Directory Domain: domain.win2k8.netapp.com
       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
[domain/default]
cache_credentials = True
case_sensitive = False
[sssd]
config_file_version = 2
services = nss, pam
domains = DOMAIN
debug_level = 7
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
filter_groups = root
[pam]
[domain/DOMAIN]
id_provider = ldap
auth_provider = krb5
case_sensitive = false
chpass_provider = krb5
cache_credentials = false
ldap_uri = _srv_,ldap://domain.win2k8.netapp.com
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/centos64.domain.win2k8.netapp.com@DOMAIN.WIN2K8.NETAPP.COM
krb5_server = domain.win2k8.netapp.com
krb5_realm = DOMAIN.WIN2K8.NETAPP.COM
krb5_kpasswd = domain.win2k8.netapp.com

Servers

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!

Wrap-up

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::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.

idmu

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

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.

blogfieldofdreams

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

DataCenterDude

I also used to write for datacenterdude.com 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 whyistheinternetbroken@gmail.com.

LDAP::LDAP servers and clients and bears, oh my! – Part 5

UPDATE: I realized today that I wrote this same topic twice, in two different posts. This one should be considered the older effort. The newer, up-to-date post is here:

https://whyistheinternetbroken.wordpress.com/2015/07/29/ldap-servers-clients/

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 the bind portion of LDAP.

We’re off to see the Wizard of LDAP!

Clients vs. Servers

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.

Clients

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.

Others, like Linux OSes, need you to install packages to run client operations. Some common Linux-based LDAP clients include:

And many more!

When you install a client, you are far from done. You now have to configure that client to talk to the LDAP server. This requires a plethora of necessary information, including:

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?)

Bind/Login information.

This will depend on type of bind supported by the server. Can be username/password, Kerberos SPN, anonymous, etc. For more detailed info on binds, see part 2 of this series.

LDAP Search Information

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.

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: 10.228.225.120
                 Active Directory Domain: domain.win2k8.netapp.com
       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
[domain/default]
cache_credentials = True
case_sensitive = False
[sssd]
config_file_version = 2
services = nss, pam
domains = DOMAIN
debug_level = 7
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
filter_groups = root
[pam]
[domain/DOMAIN]
id_provider = ldap
auth_provider = krb5
case_sensitive = false
chpass_provider = krb5
cache_credentials = false
ldap_uri = _srv_,ldap://domain.win2k8.netapp.com
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/centos64.domain.win2k8.netapp.com@DOMAIN.WIN2K8.NETAPP.COM
krb5_server = domain.win2k8.netapp.com
krb5_realm = DOMAIN.WIN2K8.NETAPP.COM
krb5_kpasswd = domain.win2k8.netapp.com

Servers

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.

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!

LDAP::Distinguishing Distinguished Names in LDAP – Part 4

This post is part 4 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 Distinguished Names (DN) in LDAP.


In LDAP, objects are stored in a hierarchical structure, much like folders in a file system. Each object has a unique identifier so that LDAP queries can find them quickly. These identifiers are known as “distinguished names.”

homer-distinguished

Contrary to how it sounds, these attributes are not fancy by any stretch of the imagination. In fact, they can be downright messy, depending on how the LDAP objects are laid out.

Distinguished Names (DNs)

Distinguished Names are the full paths to objects in LDAP. They are comprised of a number of Relative Distinguished Names (RDNs).

Relative Distinguished Names (RDNs)

RDNs are components of the Distinguished Name. In the diagram below, “DC=domain,DC=com” is a Relative DN to the DN of CN=Pat, OU=Users, DC=domain, DC=com.

ldap-directory-structure

How do these get messy?

In very large LDAP environments where objects are laid out in a deep folder structure, a DN can start to become very long. Each time a new object is added as a child to another object, another RDN is added to the DN. As a result, you could see a DN that looks like this:

CN=Pat, OU=Super, OU=Cali, OU=Fragi, OU=Listic, OU=Espi, OU=Alli, OU=Docius, OU=Users, DC=domain, DC=com

To avoid long DNs, you could use a wide folder structure. This is one suggested best practice for designing a LDAP environment, if only to make managing objects easier.

ldap-deep-wide

Types of Relative Distinguished Names

In the examples above, we see abbreviations like OU (Organizational Unit), DC (Domain Component) and others. These are simply different types of RDNs. There are a slew of these that are used in various LDAP schemas. The following table (from Microsoft’s MSDN) shows a list of typical RDNs used in LDAP.

String Attribute type
DC domainComponent
CN commonName
OU organizationalUnitName
O organizationName
STREET streetAddress
L localityName
ST stateOrProvinceName
C countryName
UID userid

As to what “type” of RDN to use, there really isn’t a wrong answer. These are simply identifiers. If there’s any “best practice” for this, it would be “make sure it makes sense.” For example, don’t use STREET to identify a user. Use something like CN instead. Sure, it’s possible to use STREET for users, but…

just-because

Reserved characters

There are rules to what characters can be used in RDNs. If these characters need to be included in the RDN, they have to be “escaped” with a backslash (\). The following characters are reserved for specific functions, so they require an escape.

Reserved character Description Hex value
space or # character at the beginning of a string
space character at the end of a string
, comma 0x2C
+ plus sign 0x2B
double quote 0x22
\ backslash 0x5C
< left angle bracket 0x3C
> right angle bracket 0x3E
; semicolon 0x3B
LF line feed 0x0A
CR carriage return 0x0D
= equals sign 0x3D
/ forwards slash 0x2F

Modifying DNs

In LDAP, it’s always possible to modify a DN. However, the best way to do that is via the automated tools available from the LDAP server provider. For example, in Active Directory LDAP, we can modify DNs via ADSI Edit. But the better way to do this is via the Active Directory Users and Computers interface. ADSI Edit should only be used when necessary. However, keep in mind that native Windows LDAP management tools are going away in the future, so you may have to resort to a 3rd party management tool. In non-Windows LDAP, DN modification can be done manually via LDIF files, or via the provided GUI interface. As always, check with your vendor for the best ways to do this.

Distinguished, but often forgotten

Distinguished names are often overlooked when implementing or troubleshooting LDAP environments. It’s important to keep them in mind and avoid not being able to see the forest for the trees…

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?

LDAP::Schemin’ with schemas – Part 3

This post is part 3 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 schema portion of LDAP.

homer-ldap-schema

What is a schema in LDAP?

A schema, as used by LDAP, is a set of defined rules that govern the kinds of information a server can hold. These include, but are not limited to:

  • Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.
  • Matching Rules—Provide information about how to make comparisons against attribute values.
  • Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.
  • Attribute Types—Define an object identifier (OID) and a set of names that may be used to refer to a given attribute, and associates that attribute with a syntax and set of matching rules. These are defined in detail in RFC-2252.
  • Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes.
  • Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.
  • Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.
  • Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.

When dealing with LDAP schemas, there are a subset of the above that we deal with on a regular basis for name services/identity management.

Attribute syntaxes

Attribute syntaxes define what type of information can be stored as an attribute. These are defined by an object identifier (OID) and control whether an entry can be in Unicode, integer format or other format.

The following table from OpenLDAP.org shows some commonly used attribute syntax OIDs:

Name OID Description
boolean 1.3.6.1.4.1.1466.115.121.1.7 boolean value
directoryString 1.3.6.1.4.1.1466.115.121.1.15 Unicode (UTF-8) string
distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 LDAP DN
integer 1.3.6.1.4.1.1466.115.121.1.27 integer
numericString 1.3.6.1.4.1.1466.115.121.1.36 numeric string
OID 1.3.6.1.4.1.1466.115.121.1.38 object identifier
octetString 1.3.6.1.4.1.1466.115.121.1.40 arbitary octets

Microsoft Active Directory LDAP uses different OIDs for their attribute syntaxes. These can be seen in the schema via ADSI edit. As an example, while OpenLDAP uses an OID of 1.3.6.1.4.1.1466.115.121.1.15 for Unicode (UTF-8) strings, Active Directory uses 2.5.5.12:

attr-syntax-unicode

These attribute syntaxes are generally not modifiable.

Object classes

Object classes in LDAP are collections of specific types of attributes that help LDAP searches execute more efficiently. When a search is kicked off, the objectClass is passed in the search. For example:

Filter: (&(objectClass=User)(sAMAccountName=ldapuser))

The above objectClass is defined as “User,” but an also include (but is not limited to):

  • Person
  • organizationalPerson
  • Group
  • Top

For a complete list of objectClass attributes, see: http://oav.net/mirrors/LDAP-ObjectClasses.html

In Active Directory, the objectClass can be modified and viewed via the Active Directory Users and Computers in advanced view via the Attribute Editor tab.

attribute-edit-objectclass

When a LDAP search runs, it would pass the defined schema attribute for objectClass as defined in the client configuration. In NetApp’s clustered Data ONTAP, it would be passed via one of the object-class attributes:

cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields nis-object-class
 (vserver services ldap client schema show)
vserver schema  nis-object-class
------- ------- ----------------
SVM     AD-IDMU nisObject
cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields nis-netgroup-object-class
 (vserver services ldap client schema show)
vserver schema  nis-netgroup-object-class
------- ------- -------------------------
SVM     AD-IDMU nisNetgroup
cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields posix-group-object-class
 (vserver services ldap client schema show)
vserver schema  posix-group-object-class
------- ------- ------------------------
SVM     AD-IDMU Group
cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields posix-account-object-class
 (vserver services ldap client schema show)
vserver schema  posix-account-object-class
------- ------- --------------------------
SVM     AD-IDMU User

In a Linux client like RedHat running SSSD, it might look like this:

# cat /etc/sssd/sssd.conf | grep class
ldap_user_object_class = user
ldap_group_object_class = group

In general, we could think of objectClasses like we’d think of how we use a phone book’s Yellow Pages. We don’t look for things in the Yellow Pages by name, but rather by type of business. If we wanted to find a grocery store, we’d use an objectClass of “groceryStore” to filter our results to speed up our search.

Attributes

The most relevant and necessary parts of a LDAP server’s schema (at least when it comes to client configuration) are the attributes themselves. These are the specific entries in the LDAP schema that define who and what the object is, specifically. If we extend our Yellow Pages analogy, after we find the objectClass=groceryStore, these would be the phone number, address, etc. of the grocery store. That information happens to be the most critical portion of the object, as they tell us what we need to know about the object we were looking for.

In a LDAP server used for name services/identity management, the attributes will tell us information about users, groups, hosts, netgroups, etc. such as phone numbers, email addresses, physical location, IP addresses, UID/GID for UNIX based permissions, SIDs for Windows environments and many, many more.

Attributes are broken down into two categories: the attribute and the value.

The attribute

With regards to name services/identity management, an attribute that might matter to us would include (but are not limited to):

  • uid
  • uidNumber
  • gid
  • gidNumber
  • memberOf
  • objectClass
  • primaryGroupID
  • objectSid
  • sAMAccountName

These attributes are defined in schema templates of clients and should be compliant with RFC-2307 standards for a valid LDAP server configuration. Common LDAP servers such as Microsoft Active Directory, OpenLDAP, Sun Directory Server, RedHat Directory Server (and IdM), Apple Open Directory, Oracle Internet Directory, Vintela… these all fall under the RFC standards. For a list of LDAP software available, see this Wiki entry.

The value

This is the portion of the attribute that populates the information we want to be used in queries. For example, if I have an attribute of uid, I can populate the value with the list of UNIX names I want to use in queries.

When a LDAP search is issued, the attribute and value are passed.

Filter: (&(objectClass=User)(sAMAccountName=ldapuser))

In the above, both objectClass and sAMAccountName are attributes. User and ldapuser are values.

How do I change them?

Attribute values are editable in most cases, but in some cases, the LDAP schema might have set the value to “read only.” This is fairly common in Active Directory as a means of idiot-proofing/CYA. But there often are ways to modify the schemas to allow editing of these attributes, if desired. Always do this with caution, and ideally, in a lab first and with the guidance of your LDAP server vendor.

Attributes themselves are also editable. We can also create custom attributes in LDAP if we choose. 3rd party LDAP products like Vintela do this for you. But in most cases, it’s best to leave the default schemas alone, and instead, modify the clients to query the attributes we have populated. Many clients have default schema templates, including NetApp’s clustered Data ONTAP.

 Schema Template: AD-IDMU
 Comment: Schema based on Active Directory Identity Management for UNIX (read-only)
 RFC 2307 posixAccount Object Class: User
 RFC 2307 posixGroup Object Class: Group
 RFC 2307 nisNetgroup Object Class: nisNetgroup
 RFC 2307 uid Attribute: uid
 RFC 2307 uidNumber Attribute: uidNumber
 RFC 2307 gidNumber Attribute: gidNumber
 RFC 2307 cn (for Groups) Attribute: cn
 RFC 2307 cn (for Netgroups) Attribute: name
 RFC 2307 userPassword Attribute: unixUserPassword
 RFC 2307 gecos Attribute: name
 RFC 2307 homeDirectory Attribute: unixHomeDirectory
 RFC 2307 loginShell Attribute: loginShell
 RFC 2307 memberUid Attribute: memberUid
 RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup
 RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple
ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName
 Vserver Owns Schema: false
 RFC 2307 nisObject Object Class: nisObject
 RFC 2307 nisMapName Attribute: nisMapName
 RFC 2307 nisMapEntry Attribute: nisMapEntry

Schema extension

By default, Microsoft Active Directory do not contain the UNIX attributes needed to use the server as a UNIX Identity Management server. The schema had to be extended to create the necessary attributes types to allow for proper UNIX-based authentication. Extending the schema in domains with multiple domain controllers is non-disruptive; only one server needs to have the schema extended and then it can replicate to the other servers. For information on extending schemas or enabling identity management, see the TechNet article on IDMU.

UNIX-based LDAP servers such as OpenLDAP don’t have to do this, as they are intended for use with UNIX authentication by default.

Replication of schemas

One of the reasons I like Microsoft’s Active Directory so much for UNIX identity management (aside from the integration of services and pre-existence in enterprise environments) is the built-in schema replication. Want to create a new LDAP server? Cool. Add it to the domain. You’re done.

Microsoft Active Directory replicates every 15 minutes by default. That means all schemas, attributes, etc. get copied over to all domain controllers in a domain.

In a forest with multiple domains, it’s possible to replicate UNIX attributes across those domains to allow cross-domain UNIX authentication. So if your company acquires another company, you can simply add their domain to your forest and enable replication of their UNIX attributes and keep using your existing set up. I describe how to do this in TR-4073 on page 103.

Non-Windows LDAP servers also have the capability to replicate schemas and attributes, but they need configuration and are not as robust as Windows, in my opinion. This is changing somewhat with RedHat Directory Server/IdM, especially with RedHat 7 and the ability to integrate into Active Directory domains. I’ll cover that set up in a later blog post. 🙂 (thanks to Natxo for pointing out that omission)

What else?

LDAP schemas are the lifeblood of directory services, so it’s important to understand them as best as possible. Hopefully this post has helped clear some things up.

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?

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.

simple-bind1

simple-bind2-plaintext

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:

ldaps

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:

tls-aes

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

tls-ldap

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.

3. SASL

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:

cdot-ldap-sasl

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
 cifs/2k8-dc-1.domain.win2k8.netapp.com
 kadmin/2k8-dc-1.domain.win2k8.netapp.com
 ldap/2K8-DC-1.domain.win2k8.netapp.com/ForestDnsZones.domain.win2k8.netapp.com
 ldap/2K8-DC-1.domain.win2k8.netapp.com/DomainDnsZones.domain.win2k8.netapp.com
 TERMSRV/2K8-DC-1
 TERMSRV/2K8-DC-1.domain.win2k8.netapp.com
 Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/2K8-DC-1.domain.win2k8.netapp.com
 DNS/2K8-DC-1.domain.win2k8.netapp.com
 GC/2K8-DC-1.domain.win2k8.netapp.com/domain.win2k8.netapp.com
 RestrictedKrbHost/2K8-DC-1.domain.win2k8.netapp.com
 RestrictedKrbHost/2K8-DC-1
 HOST/2K8-DC-1/DOMAIN
 HOST/2K8-DC-1.domain.win2k8.netapp.com/DOMAIN
 HOST/2K8-DC-1
 HOST/2K8-DC-1.domain.win2k8.netapp.com
 HOST/2K8-DC-1.domain.win2k8.netapp.com/domain.win2k8.netapp.com
 E3514235-4B06-11D1-AB04-00C04FC2DCD2/277b3b64-265b-4612-a5ac-b06adf2a39b8/domain.win2k8.netapp.com
 ldap/2K8-DC-1/DOMAIN
 ldap/277b3b64-265b-4612-a5ac-b06adf2a39b8._msdcs.domain.win2k8.netapp.com
 ldap/2K8-DC-1.domain.win2k8.netapp.com/DOMAIN
 ldap/2K8-DC-1
 ldap/2K8-DC-1.domain.win2k8.netapp.com
 ldap/2K8-DC-1.domain.win2k8.netapp.com/domain.win2k8.netapp.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.

C:\>nslookup
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 = 10.228.225.120
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::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.

facepalm

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.