Joining Active Directory

[compendius]

We are considering purchasing a NetApp filer and have a few questions concerning AD integration -

We want to use our AD for identity, auth, ACLs etc and are aware that you can join a NetApp to a Windows Domain.

1) I have in the past played around with Samba and idmap on Linux, which effectively joins a Linux system to an AD domain. Does the ONTAP OS work with the same technology?

2) How robust is the NetApp AD integration? Are there any major gotchas?

3) Does it work well in an up to date Windows Server 2008 R2 domain?

4) Are there any limitations like the number of users in a domain (we have around 70,000)?

5) How easy is it to apply and manage 70,000 user home directory quotas on a NetApp?

Anything else we should know about.

Thanks

[compendius]

A long noticeable silence to my questions.....but I managed to get hold of the NetApp simulator to test and find out for myself...(ONTAP Sim 7.3.4)

1) I have in the past played around with Samba and idmap on Linux, which effectively joins a Linux system to an AD domain. Does the ONTAP OS work with the same technology?

Pass on this one...except it is important to note that time has to be in sync with the Windows DC or Kerberos fails and all bets are off.

2) How robust is the NetApp AD integration? Are there any major gotchas?

Seemed pretty robust. This rights model is confusing though. Inherited rights appear to fall through to CIFS shares from the qtree. It is hard to manage these efficiently, and get Windows to see a 'correct' view of the world.

3) Does it work well in an up to date Windows Server 2008 R2 domain?

Yes, it joined the domain no problem

4) Are there any limitations like the number of users in a domain (we have around 70,000)?

There was no obvious limitation. All users were there when the SIDs were queried on the Filer.

5) How easy is it to apply and manage 70,000 user home directory quotas on a NetApp?

Not very if they are all different. It involved adding user quota entries to /etc/quotas file and restarting the quota service.

If you have lots of generic quotas then a wild card can be used, which is  a one liner to cover everyone.

The third party software recommended for managing quotas looks very pricey.

The quotas do however get displayed on the Windows clients CIFS shares which is good.

[Darkstar]

Regarding your point 2.

ACLs on NetApp work exactly like they do on a Windows server. It is only confusing if you're expecting something else to happen (as on Samba for example 😞

On Windows (and thus, on NetApps, at least if the qtree security style is set to "ntfs"), ACLs are inherited to subdirectories if you chose so. The security on the filesystem has nothing to do with the "share-level" security on the CIFS share. The recommendation (also from Microsoft) at this point is: use "everyone/full control" as share level security and manage securities on the filesystem.

You can also enable "access-based enumeration" on the shares so that users don't see directories they have no access to.

You can script any security/ACL changes with "cacls" or "xcacls" from the Windows resource kit, if required.

If you could explain a bit more where your confusion is I could try to clarify

regarding limitations: yes, there are some: no EFS (encrypted file system), no NTFRS (native replication), max. kerberos ticket size of 64k (I heard some windows implementations allow larger tickets?). Everything else is there, even DFS-Links and hidden shares without the trailing "$"

-Michael

[compendius]

Thanks for your comments.

The ACLs for a novice 'NetApper' were a little confusing. When setting up a qtree from the web interface there was no obvious way to check or set the ACLs. You could only set the style of ACL like 'NTFS' in my case for example. Qtree default ACLs gave Everyone access to it.

So when I created a CIFS share under the qtree, the world had full inherted access as the share also defaulted to everyone.

You imply  the only way to change the default inherited ACLs would be from Windows tools AFTER creating the Qtree. It would seem that if you create a Qtree from the NetApp command line and specify the permissions then they are in the Unix, not NTFS form, and we intend to only use NTFS.

from http://www.wafl.co.uk/qtree/

"When you create a qtree, you can optionally specify the file permission bits of the qtree using the mode option. The format of the mode option is similar to UNIX permission bits: 0755"

Your point about access-based enumeration is very useful to know. Ideally we would like Windows users to view their home directory and the .snapshot directory, nothing else. Presumably this feature will enable this to happen. Does the feature have a performance hit, as there is a similar function in SAMBA that does the same thing, but has a slight overhead in slowing down access while filtering the view?

[Darkstar]

A qtree on the NetApp is (for all CIFS and client access functions) 100% equal to a directory. I.e. if you create a qtree, you essentially create a directory in the filesystem. This directory defaults to the inherited security of the volume on which it is created, except if you remove the "inherit" flag from the ACL in the volume's root directory. This is the same as on windows, where if you create a directory called "D:\TEST", it inherits its ACLs from the ACLs on D:\

Usually you add an administrative CIFS share on the volume root (i.e. "cifs shares -add USERHOMES$ /vol/vol_UserHomes" if your volume is called vol_UserHomes for example). You then connect to it and set the ACLs on all qtrees and directories that you find inside. You can then chose to inherit the ACLs or not. Also, if you map the USERHOMES$ share to a drive letter you can change the ACLs of the volume root directory. It really works the same way as on a windows server.

There's, sadly, no way to set/change NTFS ACLs on a file/directory via the NetApp command line. You can only set Share-level security or import a so-called "fsecurity" batch file which uses an MS SDDL config file to set ACLs on whole volumes/directories.

The Mode-bits you set when creating the qtree only apply to a UNIX style volume/qtree, which you should really avoid if you're sharing via CIFS (i.e. make sure that your volume AND all your qtrees are set to NTFS security style, not MIXED and not UNIX).

Access-based enum is enabled on a per-share basis and has no noticeable impact on performance since WAFL directly stores windows ACLs and thus doesn't have to do any sort of mapping to determine whether a given user should see a directory or not.

I really encourage you to read the "File Access and Protocol Management Guide" which describes these things in great detail. You find it on your filer (if you have installed the documentation) via http://<your-filer-ip>/na_admin (click on "Documentation"). Also the Storage Management Guide describes how volumes and qtrees work.

-Michael

[compendius]

Thanks again.

You are implying that I should actually read the documentation...and before playing with it

No seriously, I will read and absorb.

Your advice is much appreciated.