I should be ashamed of myself just posting this, but confession is the first step of healing (or something like that), right? For years, I put off configuring Active Directory LDAP integration for authentication on our storage arrays. Perhaps at the beginning, it was due to complexity and overload, but more recently, it just wasn’t that important to me. We’ve had strong, complex passwords in place on the built-in accounts, so the real “risk” was accountability–who performed an action under that login. So while I begrudge any positive sentiment toward auditors, I’ll throw some props to them for the motivational boost to eliminate these shared access methods.

The funny thing is that most of what follows in this 3-part series was pretty easy. Parts 1 & 2 took a whopping hour or two. Shame on me. So if you’re reading this and have any of these arrays, take the plunge and raise your security posture with an easy afternoon project.

Pure Storage

pure_ldap_pureuserLet’s give this boulder some downhill momentum with the easiest of the three arrays. It only makes sense that Pure takes the cake on this since the rest of what they do is equally simple–initial setup, vCenter Plug-in, volume provisioning, etc.

Pure actually pushes its customers to setup external authentication by restricting the local user database to the “pureuser” account with which all arrays ship. Thus, every admin of Pure knows this default launching point.

Security Storage Technology