Comparing NNTP Access-Control Methods

Pros:

• Leverages your understanding of NT security. If you know how to set permissions on file-system folders, you know how to govern access to newsgroups.
• Leverages the existing user/group database. If you've already populated a domain da tabase, you can reuse those names when configuring NNTP security.

Cons:

• Works only on NT.
• Every NNTP user needs an NT domain account. Not a problem for your staff, usually. But if you park an NNTP server on the Internet so that your staff can collaborate with the outside world, you'll have to create one or more accounts for these outside users. That's scary.
• Access schemes are tied to file systems. If you want to migrate conferences from one NT box to another, you have to migrate a file-system subtree and all its associated permissions. If you want to temporarily disable authentication, you're stuck. Recursively granting full access to everyone is a one-way transformation from which you cannot easily recover.

Pros:

• Works on all Netscape-supported OSes.
• Doesn't export OS accounts to Internet users.
• Supports client authentication. If you specify a mapping between a field of a client certificate (e.g., Common Name) and an LDAP attribute (e.g., user name), you can dispense with user-name/password log-ins and control access entirely by means of certificates.

Cons:

• You have to learn how to use the local LDAP database bundled with Netscape servers or else acquire, install, and learn how to use a Netscape or third-party directory server.
• You have to populate the LDAP directory; there's no migration tool for capturing existing OS-based accounts.