7 Replies Latest reply: Aug 17, 2009 5:45 PM by D Little
D Little Level 1 Level 1 (10 points)
I cannot seem to set up blog security the way I want it. I would like anyone wanting to view or edit to have to authenticate via OD before being allowed access. Wikis are working and authenticated via OD as expected. The site otherwise operates as expected.

SETUP: OS X Server 10.5 w latest updates is running with OD Master, DNS, Mail and Web services (among others). Server Admin:MyServer:Access:Blog is specified only for the desired group. Website is enabled and running with SSL, and in Web Services all boxes are enabled (webmail, blog, wiki & blog, web calendar, mailing list). The desired group is also listed their in Web Services. In WGM, under the desired group, I enabled Mailing list, wiki & blog, web calendar, mailing list archive for the website to allow "authenticated users" to write and the view.

It seems to me this should do it. I would expect this to present a username/password prompt upon entering the URL, but it doesn't. Am I missing something?

Thanks in advance.

Macbook Pro / OS X Server 10.5, Mac OS X (10.5.2), OS X / Linux / Windows Network
  • D Little Level 1 Level 1 (10 points)
    It seems I have answered my own question. I am not sure if it was also necessary to do what I have already done, but in the blog itself while logged in as the blog owner, you need to enter the admin settings and choose to make the blog readable only by authenticated users. It may or may not work if that is the only place with that setting, but it works with all the previous settings and that. There sure are a lot of redundant settings in undocumented places. Too bad this security measure relies on the user and can't be enforced on the network.
  • harry @ pmsi Level 3 Level 3 (535 points)
    In reading this post you seem to have stumbled onto the security setup you are looking for. However, the group and user priviledges are setup by the server admin in the normal course of establishing the service. So it may appear that your setup has some contradictory or absent setting(s) that didn't get the job done until an admin signed in on the blog.
    SA->General Panel-> Access sets up general and specific priviledges, WGM->Group service page sets up priviledges for the group and Directory.app->Edit priviledges can be used to fine tune the access of users.
    A specific note on page 76 of WebTechnologies_Adminv10.5 is to use the server interface and not the web interface for setting service access control lists to specify which users have access to blogs. This page also describes setting up user blog access.

  • D Little Level 1 Level 1 (10 points)
    Thanks for the input Harry. It is good info and much clearer than what I wrote.

    It might not have been clear in my original post that I am the admin and had already set access and permissions via SA, WGM and Directory.app so that nobody other than the desired group should have had any access at all. Unfortunately it did not get the job done as expected and in spite of what is in the documentation, I did have to log into the blog itself via web browser to restrict read access to only authenticated users in the authorized group. Until then, anyone on the web could have read the blog, and I did not want that.

    What still perplexes me is why when a user creates a blog it ignores the server access/permission settings and the blog is by default world readable. At least, it happens that way for some reason on my server. Now that I know about it though, I can at least fix it. Since we are a small shop, it won't be too much of a hassle to correct the blog settings each time a user creates a new blog.

    Thanks again for the reply.

  • harry @ pmsi Level 3 Level 3 (535 points)
    Hi Dan,
    Your description does sound puzzling. It seems you went through the steps. If a login popup didn't appear when you visited the group site after checking services limited to "authenticated users" then something is clearly wrong with the permissions on the files. Suggestion is to verify _teamsserver is the owner and group assigned to the /Library/Collaboration folder or wherever you store the group site data. There should be no other assigned ACL on this directory and all enclosed directory/files. If _teamsserver is the owner and only user allowed access then all the authentication checks must be done as specified in WGM or Directory.app to allow a user in. Don't assign a moderator to the group in the web site -> services panel as this will allow any admin access to the group site.

  • D Little Level 1 Level 1 (10 points)

    I didn't know that teamserver should be owner and group for /Library/Collaboration with no other assigned ACL, but just verified that it is so. That is good info to have though. I did have myself assigned as a moderator in web site services (just deleted as I am a member of the group and we don't really need a moderator), but I (and another usid for myself) are the only admins. But, I think your post just possibly illuminated something. The problem is not on the "group" blog, but on "user" blogs. I want to allow creation of individual blogs for users who are members of the group, but I still don't want them world readable and that is where the problem (no login popup) is. Is it possible that OS X Server does not allow a system admin to impose restrictions on access to "user" blogs?

    Thanks again Harry,

  • dgillesp75 Level 1 Level 1 (0 points)
    Just wondering if anyone has had any success with addressing the issue outlined in this thread - ie is it possible for the server admin to set a default so that when a user creates a user blog the setting is such that only authenticated users can read the blog (and preferably that the user creating the blog cannot access the admin settings).


  • D Little Level 1 Level 1 (10 points)
    I never did come up with anything else other than that the system admin cannot set a default for only authenticated users, let alone make it so that is the only possibility. Preventing users from accessing admin settings would be even better, if a default could be set. It seems like it should be doable. Good luck.