My name is Rusty Tucker. I'm here to present you Leveraging the Power of ACLs today. I manage the File and Print Services group in Mac OS X Server. And this session is really aimed at the systems administrators of VEXSERV. So we've got a few system admins out there and developers. Terrific. Thank you. Come to the right place. So here's what we're gonna cover today.

First of all, we're going to try and provide a lot of in-depth information that you can take home and use about the ACLs and different access control that's available in Tiger Server. We're going to provide just an overview of the options that are available to you, as well as go into pretty good depth on the file system ACL internals to really give a good solid understanding of how they are actually implemented that will help you with your deployments. Then we'll take a look at Tiger ACLs from a developer's point of view, and then go over some best practices for using and deploying ACLs in your and managing your networks. And then we'll follow up, close that with Q&A.

So let's go ahead and get started here. Go ahead and we've got three main different types of access control in Tiger Server. The first, of course, are the POSIX permissions that were still there for control of access to the file system. Building on that are the file system access controls.

Now they don't replace POSIX permissions, but really augment it and enhance the capabilities that are already present. And then the third type are the service access controls. They're not directly related, but they're very complementary to file system access controls. So let's take a look at those first, and then the rest of the time will be spent on the file system access controls.

So Service Access Control List, well what do they do? The main purpose is to control access or login to a service. So it's really like the file system access controls, but there's really only one bit of control. Can the person login or not? And this Service Access Control or SACL support, as it's often called, it's really prevalent throughout Tiger Server. We've updated a number of services to take advantage of this. Everything from Apple File Server through XGrid is controllable through the Service Access Controls. And so the UI looks like this, and we'll go ahead and take a look at demo one and show you how that's used.

So the Service Access Controls... Let me go ahead and hide that out of the way. UI looks like this. You have a control of services on the left-hand side that can be controlled, and the default option is to allow all services access to anyone that has a name and account in the directory system. This is the default behavior that we've shipped in Panther and so on.

But with the service access controls, you can control, say we have a group of users, and we can lock down all the services to only those people that are in the Daily Planet group. If we wanted just to apply all services uniquely. We can also define a separate service control list for each of the services that's present. So SSH, for example, we might want to control that to the local admins only to get SSH access into this machine.

And so that would be just drag and drop your groups from the list into the access control list for that service. Now AFP we can control separately. We could have not only the local admins, but all of the members of the Daily Planet staff could have access into that service. So we can control that. So we can control the service itself.

Now the way that we've implemented Access Control Lists really leverages the membership daemon, which is a new process and part of the base Tiger operating system. It's the same daemon that the kernel uses and other processes use for membership resolution. And you can implement in your own services access control through a very simple mechanism. And we'll just walk through some quick sample code that shows how you would do that.

The idea being you would have a well-known group in the local directory, and the access to your service would be limited to the people that are the members of that group. So in this little routine, can access service, we show the members of that group by the well-known GID. And we've authenticated a user that's identified by the user ID. And we'll pass those two to the can access service routine.

First thing we need to do is the membership daemon deals directly with unique user IDs, because it needs to have very precise notion of both users and groups and from which of the directory hierarchies they come from. So the first step to do is take the user ID you got from the login process and pass that to the member UID to UID routine to convert that to a user ID.

Since you've just authenticated this user, it would be very unusual for that to fail. So the error handling would just be too absurd on that. The next step is to take your well known account group and convert that through the member GID to UUID function. And that'll give you the group UUID.

If there's no error there, because in this case, since that's a configuration item, it might not be present in the directory system. Then you call the member check membership function, passing it the UUID of the user and the UUID of that group. Now that group can break through both the 16 group membership limits and provide nested groups. So there could be groups and other users within a member of that, within that group. If that all succeeds, then you return no error. If it fails, then you return E-Auth error, and that will be the way to provide the membership checking access.

So that's all that we're going to have on the service access controls. The next, obviously, POSIX permissions are still present, recommended still for many uses, including the BSD sections, system/system parts of the hierarchy. Typical, as everybody is probably aware, you've got the owner group and everyone, and really three basic permission bits for controlling access.

File System Access Controls build on that as an extension to the POSIX control, but it really isn't a direct replacement for it. And in this way you can have volumes of your SharePoints and volumes that have both Access Control Lists and POSIX permissions on different items there, even mixing within folders that you have.

The Access Control Lists provide you with much greater flexibility, including the capability for allow and deny inheritance so that you can pass some of the permissions from a folder onto items that are created in that folder. Obviously the capability of supporting multiple users and groups within the Access Control List and finer granularity in the permissions themselves.

And so if you were here last year, this is the kind of stack of where we made changes in Tiger to support access controls, starting from the kernel on up through POSIX, Carbon, the Samba file server, Apple file server, and in the graphic utilities and finder and server tools.

But mainly we're positioning it as a server-only feature. We have no features in the Tiger desktop that are really leveraging that, but that foundation still exists. The kernel, utilities, command line tools are all shared between the client and server operating systems. And again, positioning it for use by server admins to increase your security, flexibility, and workflow, and interoperability. within a mixed environment.

In the tooling support for ACLs, in the GUI you've got Workgroup Manager, and that allows you to enable access controls on volumes and create and edit groups and users. In Finder, there's support for viewing what those ACLs are through its Get Info window and support in copying. On the command line side, there's a number of tools, and these are present both in the server operating system and in client operating systems.

For those of you that are doing development and want to enable your client systems to do so, there's CFS ACL control, which allows you to enable support on, enable ACL support on volumes, D-Aesthetic Group for manipulating group membership, LS for displaying the options, displaying the access control lists, Chmod for editing access, ACLs, and a number of the copy engines have also been updated to support not only access control lists, but extended attributes and even back to the resource forks. So, to present the file system internals and give you a really good understanding of that, I'd like to welcome Mike Smith from CoreOS.

Thanks, Rusty. So obviously I'm Mike Smith. I work in the kernel team in Mac OS X CoreOS Development Group. I was responsible for the design and implementation of the kauth authorization subsystem, as well as the file system access control list support within the kernel. Rusty suggested that we'd be going into an in-depth discussion of the Access Control List implementation, and unfortunately I think most of you want to go home this evening.

So rather than being exhaustive, I'm going to touch on some significant points about The implementation that are particularly relevant to the use of Access Control Lists for you as system administrators or as software developers. I'm going to talk about how the Access Control Lists compose, what it contains, what you can say with it, a little bit about how privilege is computed when an operation is actually being authorized, and I'll talk a little bit about inheritance, since it's particularly important when you actually start considering the use of Access Control Lists to implement file system security policy.

First I'm going to start with a little bit of terminology, just to make sure we're all on the same page here. An ACE is not a playing card, it's an Access Control Entry. It's basically a statement about permission associated with an identity. An ACL is then a list of these ACEs.

The UID and GID you'll be familiar with. They're legacy identifiers for users and groups. In our implementation and in most others, they're integers. One of the problems that we have with UIDs and GIDs is that you need to know specifically whether a number represents a user or a group.

And so, as with many other objects in the system, we've begun to use UUIDs, which are universally unique IDs, not user IDs, to identify both users and groups. Because these identifiers are unique, we can carry them around without needing to worry about whether they identify a user or a group.

It's also worth touching on Microsoft's security identifier, which is actually a structured identifier, which also carries information related to the directory service, in which the number is actually, or the identifier is actually relevant. The model that we selected was selected for a number of reasons, including strong interoperability with other platforms, particularly Microsoft's. And so translation between these SIDs and our UUIDs is a very important part of using Mac OS X ACL support in a mixed environment.

Access Control Lists, as Rusty suggested, don't really operate in a vacuum. There's a whole bunch of security information that we associate with file system objects. The traditional POSIX mode bits, the Access Control List if one happens to be present, and objects still carry owner and group information. The combination of all of this allows us to provide functionality that's a complete superset of both the traditional behavior and the Microsoft ACL model. This gives you basically the best of both worlds. You can implement policy that comes from Microsoft world. You can perpetuate policy that you have already, or you can bring in a mixture of the two.

We've tried to keep the interfaces that you as developers would use for manipulating this information as comfortable as possible. You're familiar with, those of you who have been doing this already will be familiar with the STAT, which mod system calls, they've simply been extended. If you were at Chris Amira's session yesterday, you would have seen some examples of those in use. We also modified the POSIX ACL functions.

The POSIX ACL model itself is not terribly useful, but there's plenty of familiarity out there with the use of these functions to manipulate ACLs. And so while the list semantics themselves are different, the functionality of those functions has been slightly extended and brought over, again, just to improve the programming experience.

Talking about composition of ACLs, we need to start with ACEs. As I said before, an ACE is a statement about permission associated with an identity, either a user or a group. We have some permissions. What sort of access are we actually controlling? Are we allowing these permissions? Are we denying them? We need to associate them with someone, maybe a user, maybe a group.

It may be a group of groups. As Rusty pointed out, we support the arbitrary nesting of groups, which is actually a very powerful technique for Structuring your information control, and Rusty will touch on that later. And we also allow you to control on an ace by ace basis the inheritance behavior. Obviously, inheritance is only relevant to directories, and it controls how the entries are propagated to child objects.

I'll talk a little more about that in a bit. Once we have a list of these access control entries on an object, We're in a position to start using them to control access to the object. So the first thing that happens when we're considering an operation on an object is we work out which permissions are actually required in order to perform the operation being requested.

And so once we're on with that list, we'll take a look at the attributes on the object. And if it has an access control list, we start with that. This is fairly important. It means that the Access Control List overrides or can be used to override the POSIX permissions on an object.

Entries within the Access Control List are processed in the order that they're found. This is, again, a relatively powerful technique, although it's also possible to introduce a great deal of confusion. And so most of the tools from Chmod on upwards will tend to enforce what we describe as canonical ordering, which is all deny entries are placed first, followed by all allow entries, and then all inherited deny entries and inherited allow entries.

This allows explicit entries to override inherited entries, but it avoids the confusion that can arise if you have allow entries and deny entries mixed in. And this is relevant because as the Access Control List is processed, processing stops when all of the required permissions have been found, or when any of the required permissions are denied.

It's worth sort of working this one through a little bit in your head just to make sure that you're comfortable with it. When you hit the end of the Access Control List in the Microsoft model, access is automatically denied. That doesn't provide for a very good integration experience if you already have an existing file system with POSIX permissions. And so when we hit the end of the Access Control List, permissions that haven't been granted yet are compared against the POSIX permissions.

This runs us into an interesting situation because in the traditional model, there are a number of permissions that are implicit. If you can look up an object, typically you can obtain its attributes. You can get its size, its permissions, that sort of thing. We don't want to force you to grant those permissions explicitly on all of those objects. And so whilst there are ACL permissions that reflect the ability to obtain those attributes, they're granted implicitly. They can, however, still be denied.

This is Bigtable comparing the POSIX permission model with ACLs that we stole from another group. I'm not actually going to force you to read all of it, I just stole it for a couple of examples in here. The ACL model allows us to implement completely new permissions. The ability to take ownership on an object is something that's just simply not possible in the POSIX model unless you grant the user root access, at which point they own your system. The ACL model allows us to take ownership of the file, which is clearly not desirable, particularly in our workflow environment where all you really want to do is hand off responsibility for a file from one UID to another.

And it also allows us to separate permissions that were traditionally grouped together. Write permission on a directory in the POSIX model allows you to both add and remove entries. And it allows you to add any entry to the directory and allows you to remove any entry from the directory. With an Access Control List, however, you can grant delete permission to a specific file or specific set of files and thus again separate permission.

Finally, I'm going to talk a little bit about inheritance. Access Control Lists applied explicitly to files are great. You have a bunch of files, you can add some Access Control Lists to them. But if your file system is active, if you actually have files coming and going and moving around, you need a way to set policy for all of the files within a particular area. This is something where the POSIX model is very weak. default permissions for files are largely set by the application and by the user. There's really little or nothing that the administrator can do about default data permissions without application modifications.

So, inheritance of an ACL basically allows you to set aces on a directory object, which will be subsequently propagated to objects contained underneath that directory. Multiple subdirectories, files as they appear, that sort of thing. The kernel itself handles the inheritance of access control entries when an object is created. That's a relatively straightforward and explicit operation.

However, when you're moving and copying files, the situation is much less clear. To the kernel, a copy operation is simply the creation of a new file. It has no higher level semantic knowledge of exactly what's going on. And so for inheritance to work correctly, it needs to be implemented at a number of different levels.

The copy engines such as the Finder copy engine, CP, and others have more semantic information about the nature of a copy than the kernel does. You can copy with or without permissions depending on whether you're replicating an entire directory hierarchy with its policy or whether you're moving contents from one policy to another.

We implement copy policy relating to inheritance in CP and the Finder. Other tools that move files around need to consider very carefully whether what they're doing is transferring from a domain to another domain or whether they're attempting to maintain fidelity. So I'm going to leave it at that point and give you back to Rusty. Thanks, Mike. Thank you. Thank you, Mike.

So that really covers all the background. I think that we need to move on with the rest of the presentation. So the real trick here is how is this all going to work in a mixed network? I think it's hopefully fairly clear how it's going to work interoperate from Tiger to Tiger.

Both sides share that same ACL model and same permission model. But how is this going to work with your Panther clients, with Windows, and so on? So there's a few different flavors of fitting in. One with the Windows clients, which we've really worked strongly to make that work very, very well. Panther AFP clients, another good example. With the Panther AFP clients, they obviously have no notion of ACLs.

But unfortunately, they do have a notion of a user effective access. And even when a Panther client is talking to a Tiger AFP server, it still knows what its effective access is in any given directory. This is very important for the higher level functions, higher level applications like Finder, that want to be able to show you what your capabilities are visually, and will make decisions on whether you can copy files and so on based on that information.

So that actually works out very well. And then of course we have the Tiger AFP clients, which do have the full capability of editing ACLs and displaying those ACLs to the layers above it. And then we have a Tiger SMB client in a Windows network. It supports the ACL model and is able to translate from the Tiger ACL model to the Windows model very easily.

So with Windows clients and Tiger servers, our key goal is interoperability, and we've been working on this for the past few releases, beginning with our primary domain controller capabilities, print and file sharing, building along with that. And our Mac OS X Tiger client fully respects the Windows file permissions. And Tiger ACLs, plus the changes we've made in Samba, allow a Windows client to also participate fully as just as if we are a Windows 2003 server. Because we support the same ACL sharing bits and inheritance that they were expecting. So I'd like to bring Stephan Jones on stage to provide a demo of the Windows interoperability. And that's him.

Okay, we have a simple workflow scenario here so you can get an idea of how ACLs actually work. This is Workgroup Manager. It's our primary server tool for administering access privileges. So we have a daily plan at SharePoint here. As you can see, the owner, Apple, and we have a group daily plan that we've defined.

Two folders we have here for different workflow situations are we have, think of a simple publishing environment where you have an incoming folder where your writers would drop stories off. In this case we have privileges where you want the writers to have full control. So we've added an ace here that allows them to do that and drop their stories off.

Here's a story here that was dropped by Clark. As you can see, when this file was created, the editors, oh yeah, different scenario, yeah. And in this scenario, I want to be able to allow editors to be able to pick stories up from this folder. So I can add an additional ACE here.

I just want them to be able to read. I just want them to be able to retrieve these stories that the writers have created so they don't make any modifications in that folder. And this folder we have set aside for them to, after they do their modifications, they can drop those stories back. As you can see, they have full control here.

Just to note that these privileges are enforced over AFP in Tiger environment as well as for Windows. This server here is running a primary domain controller and we have a PC here and hopefully it doesn't have any viruses by now. Can we bring up the laptop? Okay, so this guy is a domain member of this primary domain controller and he has a mount of that Daily Planet share. So we have those two folders so we can look at the incoming.

Okay, you can see what happened when we opened the security panel. We've added, as Rusty mentioned, a Samba VFS plugin that translates between the Apple's implementation of ACLs and NT. Because there's pretty much a one-for-one permissions model, it's pretty seamless. If you look here, let's go to the advanced view. If you remember the settings from the server, you have your writers still have full control in the incoming box. Remember I added the editors ACE.

and they have read control as you can see here. And also, another thing to note is Well, in the NT model, all they have a concept of, over SMB, you're emulating an NTFS volume, and they just have concept of ACLs period. So we had the issue of, what do you do with the POSIX permissions? Because in our environment, we still enforce both. And in this case, and it still matters, they're still enforced whether they're displayed or not.

Since the ACLs are actually processed first, and the POSIX permissions, which these two ACE entries at the end represent, because remember that the initial folder had the owner, administrator Apple, and then the group administrators. And those privileges are here as inherited ACEs from the, and they show up as parent because they're actually created. Whenever you create new files or folders, the UMass of that process actually is inherited. And so those entries are very important.

So they're actually appended on the end. So when you're processing, as Mike mentioned, it processes the ACL all the way through. And if you don't get permissions from the ACL entries, which are writers or editors, it would actually fall back down and say, okay, what are the POSIX permissions? In this case, if we look at Apple and administrators.

So let's look at... So this is an incoming folder here, and remember, I'm logged in as Perry, who's an editor. attempts to write to the incoming folder. He cannot because of the ACL privileges. So, in a workflow environment, I wouldn't want to. I can read that story, but I can't actually write into that folder. I'm going to copy this locally, close incoming. I want to edit the story locally here.

So you save that file locally, and now I want to drop that file back. As an edited story, now I have access to the edit folder. Now let's look at the privileges there. And if you look at edited, you see the simple view, okay, let's look here at the more advanced view where you can see the full control editors on that folder.

Remember the ACL had editors having full control and then you also have the two POSIX ACE entries. And if you look at the actual file itself that's created, you'll see that this file has inherited, you know, editors, full control. and the POSIX permissions, Perry, because he's the actual owner of that file, and administrators was the group.

The thing we can show here is that it goes both ways, where I can actually say, "This is incoming." I say, "Well, I changed the story, but I still want my writers to still kind of overview the edits I made." So I want to come in, so I just want to add So I just want to show that you have a complete list of... The same set of groups that you have on Mac OS X are available here.

A little more difficult than a mouse. So let's select writers. I actually want it by default like we do. It'll add writers as an ACE entry with read privileges. Let me see if I select...you see how editors have full control and now writers have read access to this folder. Close it, open it again so you see. You can see writers are still there. Could we switch back to Demo 1? Let's see here. That writers now have re-control and it's interpreted by the sharing control panel, or server admin. So, that's about it.

Thanks, Stefan. If we could go back to slides, please. So that's really, that's something that you can really almost do on no other platform, is have that same intermixing of both the POSIX permissions and support for Unix clients like Mac OS X, and complete support for the Windows clients. On systems like NetApp Filers, you have got to decide up front to format your volume in one specific way or another, depending on how you want to support different sets of clients.

So just to kind of recap, we've got a high level of compatibility, really seamless integration between the Mac and the Windows clients. And that's really driven by the same set of permissions on both sides. Matching permissions and inheritance, and you've seen how we've folded that POSIX permissions and presented it to the Windows clients in a way that they can digest and use that efficiently. So next I'd like to invite Kevin Hoyt up to the stage and he'll present ACLs from a developer's point of view, kind of one of our early adopters of the APIs and capabilities. Thank you, Rusty.

So I thought I'd start off with a little bit about what I do. And I actually am the lead developer for our Mac client for IBM Tivoli Storage Manager. Hey! I'll get to you in a minute. So, because I do work for IBM, we do have some lawyers to take care of. But while everybody's reading the fine print here, everybody's heard of IBM.

How many people have heard of IBM Tivoli Storage Manager?

So the brief overview for those people that don't know what Tivoli Storage Manager is, is that we are a client-server backup solution, which means that we have a client that runs on a variety of operating systems, and our server that also runs on a set of operating systems.

Our claim to fame is that we have what we call a policy-based storage, meaning that every file or object that gets backed up to our server is associated with a policy class that determines how many versions of the file are kept and for how long. But the real point is we protect your data. We're able to manage continuing the backup if something happens with the network or something goes wrong on the client side, we'll retry. Same kind of thing happens on the restore.

We have clients for most of the operating systems out there, including Apple, AIX, Linux, Windows, and ZOS. Our server also runs on a variety of systems, including AIX, Windows, ZOS, and a few other Linux systems. But really a little bit more about the client, just to let you know that the Tivoli Storage Manager has actually been around for quite a while.

We actually have 12 years of support for the Mac OS, starting with System 6 before Mac OS was even around. But we've got 10 years here of full support, and over the last couple of years we've added the command line client and the ability to backup systems without people being logged in.

And this year we're looking at Tiger and adding support for ACLs and extended attributes. So from the point of view of the system administrator, ACLs are important way of controlling access to the data on your systems. As a backup provider, they're also important to us as one attribute of the data that's important to you.

The good news is that IBM actually has some experience on other Unix systems managing ACLs, so we have a model to follow. They just happen to be new on Tiger. And I'll spend the rest of my presentation talking about what I've learned as I implemented ACL support in Tivoli Storage Manager.

First of all, I wanted to talk a little bit about the tools that are available. We've talked about some of these before. The GUI-based tools are the Workgroup Manager. There's also the command line tool for the FS ACL. One thing that is not noted in the documentation is that if you turn on or turn off ACL support at a file system level, that file system does need to be unmounted and remounted. Otherwise, things are not going to work right.

There's also command line tools to set them on the, so we've got the file system level and the folder level, which we've also already talked about. They also can be set on files with the shmod command. The other thing that Rusty did mention is that ACLs are supported on Mac OS Server and the client, the work group manager, of course, is not available on the server.

So because we have a POSIX implementation that was introduced last year, we have a set of POSIX functions that are normal. Anyone who's seen ACLs before will recognize this set of functions and realize that they're able to manage everything that we need to be able to do with ACLs. There's a couple things that are not documented yet.

And if all you really need is ACL support, this set of functions is sufficient to do that for you. However, ACLs are really only one aspect of file security on Tiger. What we really have is a new file security model that we've been talking about, but it was really in the context of ACLs.

Most of these items we recognize as being available through stat. We've been doing user IDs and group IDs for years. The bit that's new is the owner UUID and the group UUIDs. And we really have to take those into account when you talk about being able to manage the ACL information.

And because we have a new model, we have some new functions to manage what is really a structure. And these allow you to get and set these attributes in this data structure. There's also some new functions in STAT that are really extended versions of the, of the, what are really well-known functions on the system. And just for the curious, the X means that they're extended, and the NP indicates that they're not portable to any other systems. So they're extensions and can't really go anywhere besides Mac. Unfortunately, none of these functions are documented yet.

Also that the, so those were really the C library functions that were added. There's also support that's been added to Carbon, so you can get file security information through the normal Carbon calls when you get information about files. One note here is that when you get a file security ref from Carbon, you do need to make sure you release that, otherwise you'll be leaking memory. And that's actually noted in the header file. And because we now have UUIDs we need to keep track of, there's a header file and some functions in Core Foundation to help format and view those strings, that information.

So let's take a quick look at how to retrieve the information in the file security structure so we can get this information and do something interesting with it. First of all, we need to have, obviously, local variables to hold this information, and then do a stat call or the FSGit info call to load up the file security structure.

And then make a set of calls with the Git property so that we can load it into our local variables and do something interesting with them. And then the other side of this is how do you set those, and again, you measure the information that you want to put, make the set calls to set the properties, and then SMOD the file to actually set them.

Sort of. A note here is that Schmod is not actually capable of setting the UUIDs at this point. You need to actually be able to do that. You can write a utility that uses get adder list and set adder list and do it at a lower level. The good news is that there really aren't any UUIDs in the system that you can get to yet, so the fact that this doesn't work doesn't impact much.

So some lessons that I've learned over the last few weeks as I implemented this was that things aren't documented very well. However, once you get past that, you do realize that the file security model is actually better than trying to do ACLs and the UUID information separately, because they do group it all together into one structure, one common set of files, and sets them all at once.

And actually this is really a much better solution than we have on other Unix platforms. Because they are managed all at once, there's less opportunity for things to get out of sync. For example, on some other systems, if you change the owner of a file after you set the ACLs, the ACLs no longer work. So this is all encapsulated nicely, so it works nice.

In summary, I do want to thank the Apple engineers that were able to provide me with the documentation so I could actually implement this. So, thank you. And also that knowing the Table Storage Manager is able to manage this information I think is going to be great for IBM and Apple customers as time goes on. And for those people that are TSM users, we'll be starting a beta next month to test our support for Tiger. If you're interested, please get with me after the session. Okay. Back to you Rusty.

Thanks, Kevin. So yeah, so it's a good experience for us. We learn both ways, find out where the holes are in our implementation, working with Kevin. And we've got a little bit of work to finish up some of the rough edges and really get that ready for client and a wider release and make it easier for developers to use.

But let's take a little look at ACL best practices. This by no means will be any sort of definitive list, but it's a good place to get started in thinking about ACLs and how they're going to impact the deployment on your networks. Because we're making a big switch here from very limited ability to control access on our file servers to very, very flexible and potentially confusing and complex ways. if we're not careful.

So the first thing that I would recommend in deploying this on your networks is to start with setting your everyone access to none. You can increase the security of your servers that way, and you can control then access into the servers using the SACL. So no longer do you need to allow everyone access into a server just because you're plugged into the Active Directory network and you've got 10,000 users coming out of Active Directory. You can limit that to a group or set of groups of people or individuals that really need access to the server that you're trying to run.

Another good idea is to manage permissions at the group level. Rather than setting permissions, I would say kind of the old way where you had set user permissions, try and break it down into smaller groups of users and use those as the building blocks for the ACLs in your ACES.

So what do we mean by factoring those groups and breaking them down? We can take hypothetical software organization where they had just one software group to manage all access permissions on their file servers. And in this group we had the typical scenario of engineers, QA, and management up the chain.

The first thing that folks wanted to do was break it out to that, "I want only this set of managers to have access to personnel documents and future plans kind of information on a file server." So we can break that down and to say, "Okay, let's take those managers and create just the management group out of those users." And then we've got two other independent component development groups. One for applications. And they want their own server with their private access. Or maybe they just want a SharePoint on a server that other people have access to. So we'll create a separate group just for them. And likewise for the systems group.

The work that's kind of interesting is within QA, they want, they're going to collaborate between these two teams, so they want shared access. And there's a number of test tools and test documents that they all need to share access to, so we'll create a group for them. But once we put it back all together, no longer do we compose that larger group out of individuals, but it's composed of nested groups.

And so we just take those groups and put them together, and that then becomes the larger software organization group. The benefit that you get from this type of factoring of your group policies is that as people change roles and move within the organization, you just change the groups that they're in, and they automatically get the right set of access permissions from the servers or to the services that they're trying to access. So if we move someone out of the QA organization, and make them one of the managers of the applications group, for example, just change their group from QA to the managers, and they'll have all the right access they need.

Another good thing to do is to use inheritance to control access onto files. You've seen that already in Workgroup Manager. It really is a best practice that we've encoded right into the GUI for sharing and controlling access on your servers. From the command line, of course, you can do whatever you want, but from the graphical interface, we've made it easy to control access through inheritance.

And you can see this is our default set of inheritance, which is applied to this folder, applied to child folders, child files, and to the descendants. And the graphic kind of gives you a pictorial example of how that works. So new files created no matter how deeply nested into that hierarchy. We'll be applied that access control.

There are of course many different options and combinations of bits. You can see up in the top left corner, you can just turn inheritance off altogether and have that ACE apply only to the folder and it won't be passed on to any new files and folders that are created within it. There's a lot of different options here and I would just say, you know, use them wisely.

Using propagate permissions, there you really have to decide when to do it, and the best time to do it is the propagation, what it does. Let me back up a second there. Propagation through Workgroup Manager is that it takes the inheritance rules and forces them through one of the folder hierarchies in your share points.

It doesn't have an undo, but the way to undo it is to remove the ACEs that you've applied at the higher levels and then repropagate down. If you remember from the Workgroup Manager sharing in prior versions, we had the copy of POSIX permissions. And that's still available, although it's no longer the default.

And inheritance is accumulative within a hierarchy. If we can go back to demo one. Um... We can see here where Stefan made a change to the incoming stories, but this was after a file had already been deposited there. So now writers have, editors have, no, I'm sorry, on the edited, the writers now have read access.

But since the applenews.txt was uploaded before that ACL change was made, we can go through and after we've changed the permissions, use the propagate command. So here we'll go back and select the root of the SharePoint, because we want to make sure, normalize everything that's within this SharePoint to the new permissions model that we've set up.

So I select Daily Planet, which is the root SharePoint, propagate permissions, and a sheet comes down prompting us to say, okay, what do you want to propagate? In this case, all we're interested in doing is propagating the ACL information. If we were to choose the owner name, group, or the POSIX permissions, there's no propagation rules for them in the same way that we have these inheritance bits to control the ACE entries. They would just be applied uniformly to everything within that hierarchy. In this case, we're okay with the POSIX permissions and the owners that exist, so we'll just propagate the access control list.

And as that propagates, it follows that entire hierarchy, and we can go back and find the edited news.txt, and we can see that it's got its permissions that have been fixed up to match exactly what we want, which is to give the editors full control and the writers read access. Back to slides, please.

Using the deny ACE is very powerful, but you should really think about if I have to deny a certain individual or group access to something that they are being granted, maybe it's that I haven't factored the groups in a way that's very useful. Denies can really limit your use, the flexibility, because that really short circuits the processing of the access control list. Once you hit a deny for any of the operations that are being requested, the whole operation will fail, even if it's granted later on. So that's just something to keep in mind when you're setting up permissions on your SharePoints.

The Effective Permissions Inspector is really a very useful tool. It quickly computes a user's effective access rights, so you can see exactly which bits apply to given users anywhere in the hierarchy. And it's very good to use any time after you've changed the access control list and you want to see the net effect for given users as to how it applies to them. So let's go back here. We're taking a look at a sample where Rusty, admin, and the sample readers group all have some form of access within the sample folder.

In the case for Rusty, I've been denied any read access. So we can take a look at the Effective Permissions Inspector, and that brings up the effective access for Rusty. Just from the users' perspective, it's a very useful tool. groups window, we would drag the name into that window.

And you can see I've got administrative control, but no read access and full write access, which is probably fairly unexpected since I've been denied. But as it turns out, I'm part of the admin group, so it's really only blocking out just the read access. For another user, Joe Smith, is a member of the sample readers, and if we drag his name into the inspector, we find that he has the read access just as we would expect.

Keeping it simple is always a good idea, especially when it comes to the Access Control Lists and where you're going to apply them. Use them in your SharePoints, but really keep the system areas, keep using the POSIX permissions there. And then finally, to wrap it all up, just think about what you're doing.

So that really wraps it up for today. We'll bring everyone back up to the stage here and Skip Levins will lead us in some Q&A. Thanks. Yeah, I should mention that there's, especially for developers, there's a lab coming up this afternoon writing file systems using supported KPIs, and that'll include information about ACLs. The other two sessions have already taken place, but they'll be on the DVDs that you'll get later on.