I was recently asked a number of questions about implementing moss in a public facing environment, and how to best secure the highly sensitive data which will be accessed through the portal.

In hindsight, I found the person had already made their mind up on the best approach for the security architecture either through their own personal experience of other secured systems, or from what somebody told them.

What this person was after, was a way to take a single dedicated service account (meaning a single application pool I presume), to handle multiple public facing logins securely, so that if the service account was ever breached, there would be no access to confidential data.

It seemed that after politely explaining that this holy grail is not possible if the public front-end remains available for anyone in the world to attempt a login, there had to be additional security approaches such as Kerberos, smart cards, or providing a stripped down read-only aspect of non-sensitive information.

If there is a way to achieve these requirement as mentioned above, please do share as I’d be most interested to understand how MOSS 2007 can accomodate this strategy.

Upon reflecting this a bit further, I could have better explained that introducing Portal to the public, there are mandatory requirements that further expose the most service if you want to allow logins to some degree.  With access mappings, those potential breaches can be kept to a minimum.  For each WFE, there are multiple services, or at least application pools to consider for access to the backend databases…

Some additional sites/blogs that seem close to explaining this in a general manner:

http://cregan.wordpress.com/2006/12/08/moss-setup-service-accounts/

http://blog.tomaselfving.com/2008/01/security-features-in-moss-2007.html

http://www.sharepointproconnections.com/Articles/tabid/149/nodeid/1873/Use-Kerberos-to-Secure-MOSS-2007-.aspx

This guy has a nice post on what I am getting at:

http://www.winblogs.net/index.php/2009/09/30/a-few-powershell-useful-tricks/

Where I take mine a little further, is that I’ll run this command either on a temp drive or a UNC path for interrogating logs on remote servers:

cat “\\servername\c$\Program Files\iis\w3xxxx.log” | findstr interestingString

in more recent versions of the RDP software, the switch has changed from /console, to /admin.  give that a try and all should be fine for those all-important console sessions via RDP.

mstsc /v:servername /admin

Thanks to this guy and his blog for the solution:

http://www.lehmkuhl.za.net/blog/post/2008/08/19/MSTSC-console-not-working-anymore.aspx

There are quite a few people who’ve pounded their heads against a wall trying to open documents in a MOSS environment, only to find they default to read-only.  This is despite either clicking on the document, or selecting the ‘Edit in Microsoft…’ menu item.  When you go to save the document, it prompts that it has been opened as read only and cannot be saved.

I tried some of the below search strings without much luck:

Edit Document requires a Windows SharePOint Services-compatible applicaiton and Microsoft Internet Explorer 6.0 or greater

Dllregisterserver in owssupp.dll failed.  Return code was: 0×80070716

Solution:

Despite some posts hanging around stating there is none, this has worked for me.  Rename the following file (whichever version of office you have between xp and 2007) and run a repair on the Office installation (You do have the Sharepoint Services Support tools installed, right?)

For me this file was in:  C:\Program Files\Microsoft Office\OFFICE11\OWSSUPP.DLL

Restart your browser, and now the appropriate office app will fire up in a new window (as opposed to the seamless ‘read-only’ view) for editing!

I watched a request go through a service desk setup recently asking for all users who use a particular application.  While at first this sounds trivial, the application is a heavily used flat-file system which has security enforced via Group Policy permissions.  This means that nested groups among all the various security groups makes this a tedious task going through active directory.

Enter the 2003 active directory commands complete with pipeline example of my end result.

dsquery group -name *funky* “dc=mystery,dc=localzoo” | dsget group -members | dsget user -display

That’ll bring back the nice display name, of all users, who belong to any group that has ‘funky’ in its name.

There is probably a smooth way to list out each group, then list out each user in each of those groups (to include the duplicate names), but that hasn’t been asked for..  i suppose that could be done by taking the first part of the pipe, then running the second and third piped commands against each group that is returned… that’d be the way to do it for say less than 10 groups… any more than that though, I’m sure powershell can come to the rescue.