如果说刚才我们走通了最基本的流程，接下来我们则需要对ADLS Gen2的特性进行深度的测试，尤其是针对其“文件系统”的设计目标和大数据应用的典型场景来进行实操体验。在本文中，我们先聚焦ADLS Gen2的权限控制。
我们知道传统的存储账户主要依靠Access Key和SAS token等方式来进行身份认证，并且在权限控制的粒度上比较粗放，只能设置到整个存储账户或是Blob容器的粒度。而在ADLS Gen2中，一般推荐使用集成度更佳的Azure AD进行访问身份认证(Access Key和SAS token也同样支持)，而权限方面的控制则可以非常精细：不仅支持文件系统粒度的RBAC权限指定，而且引入了类似POSIX的ACL体系，使得用户可以将权限设置下沉到目录乃至文件的级别。这样一来，ADLS这个大数据存储服务相当于提供了类似Linux文件系统的权限管理能力，极大地满足了企业级数据平台在资源管控和权限治理方面的需要。
接下来我们对于权限进行一个基本尝试。我们在cloudpickerfs文件系统中新建zone-a和zone-b两个目录来模拟企业不同业务领域的数据。
然后我们在Azure AD中新建一个用户Karl：
现在我们希望Karl拥有整个文件系统的读权限，但还能够对zone-a进行修改和写入。该需求应该如何实现呢？在ADLS Gen2上可以轻松地结合使用RBAC和目录ACL来达到目的。我们先为Karl添加文件系统粒度的Storage Blob Data Reader角色，这使得Karl可以基于RBAC权限机制读取cloudpickerfs这个文件系统中的所有数据：
然后再在Azure Storage Explorer中定位到zone-a，对该目录赋予Karl读写及执行权限，这样Karl就能够实现对于zone-a这个目录的完全控制。可以看到，这里的操作体验与Linux/Unix中的ACL权限机制非常接近：
（图中Default一栏对应的是目录中子项将继承的权限）
权限设置完成后，我们接下来使用一台Linux VM通过AzCopy这个工具来进行相关权限的实操验证。AzCopy作为微软官方的文件复制工具，已经全面地添加了对于ADLS Gen2的支持。
首先我们使用Karl的身份进行AzCopy的登录，注意需指定tenant-id参数为用户Karl所属AD的id：
./azcopy login --tenant-id xxxxxxxx-yyyy-zzzz-zzzz-xxxxxxxxxxxx To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ******** to authenticate