| Title: | WinNT-Clusters |
| Notice: | Info directories moved to DECWET::SHARE1$:[NT_CLSTR] |
| Moderator: | DECWET::CAPPELLOF |
| Created: | Thu Oct 19 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 863 |
| Total number of notes: | 3478 |
Has anybody run into this issue? Thanks, Steve -----Note from Customer---------------- The Clusteradmin account manages failover of the shared disks between clustered machines. It is a service account that has administrative privledge. I turned clustering on with a pair of Alphas in the OC last week. We are using the latest release of the clustering technology. PROBLEMS: * The clusteradmin account can not recreate shares on directories that it doesn't have explicit permission in, i.e. User directories. We found this out when we rebooted the cluster. The Clustering software actually deletes the sharepoint. It can't be recovered, only regenerated. We created 460 user directories on that machine and the user was the only one with permission into their directory. When we rebooted the server, no user shares were there. I fixed the problem by granting the clusteradmin account FULL control inside every user directory. Which brings me to the second problem. * I have been selling NT based on its security. A user should have personal space on a server that is free from prying eyes and can't be viewed by anybody. An administrator can always take ownership of a users personal directory and grant themselves the right to view and manipulate files there, and this event is recorded in the audit logs of the server. So we have accountablilty. The Clusteradmin account circumvents all of that. Anybody who knows that account password can view and modify users files inside the users directory and we have no accountablility of the action. If you wrote a PA on me, would you want me to see it, or modify it before it was complete? If it's on your local machine I can get it in about 3 min. If it's in your personal area on the server and I know the Cluster admin account password, I can get it in about 1 min. Otherwise I would have to take ownership of your files and the audit would show that I did. SOLUTIONS: * Remove the clustering software and the technology. This would bring us to a manual failover situation that requires physical manipulation of the hardware when failures occur. This is currently the only viable course of action if user file integrity and security are required. * Give the Clusteradmin account full directory permission at all share points. This is a management decision. * Share the USER directory and not the individual users directories. This works fine with NT as the client but doesn't work at all with Windows 95 or WFW as the client. I can get technical here if you like.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 669.1 | Why don't you use Administrator? Or is there another reason for not using it? | SUTRA::pcbu3.vbe.dec.com::Bats | Speeding, speeding, I'm always speeding | Sun Mar 02 1997 13:34 | 9 |
Or just the real Administrator account! Problem solved. There's no need to specifically use the account name Cluster Admin. As long as the account has admin privs. In this case the customer want's something that only Administrator can can do. Just change the account used to start the services into Administrator. Pjotrr | |||||
| 669.2 | limitation of NetShareAdd() | DECWET::LEES | Will, NTSG DECwest, Seattle | Fri Mar 14 1997 16:24 | 6 |
The account that the cluster service runs under must be a domain account and must have local dministrator privileges on the cluster server systems. The problem appears to be that NetShareAdd, the api which creates shares, requires the current user account to have read access to the directory. This is also true without digital clusters, and with Wolfpack. | |||||