If you’re ever in need of converting your existing web applications within SharePoint to claims authentication from classic auth, you’ll need to run the following commands.
In order to do this, you’ll need to use the SharePoint PowerShell command prompt and run the commands in the order below under your farm service account:
Need to give a service account access to a web application in SharePoint 2013? Easy! Just run these two PowerShell commands as the farm service account in the SharePoint PowerShell command prompt:
$webApp = Get-SPWebApplication http://contoso.com
$webApp.GrantAccessToProcessIdentity("CONTOSO\svcacct-contoso")
Done.
In SharePoint 2010, if you had other domains that you needed to lookup users on in order to give them access to a site, it just worked without having to do any further configuration.
Not so with SharePoint 2013. You must add each domain and sub-domain to each web application to be able to perform user lookups from within the people picker.
So how do you do this? Well, with PowerShell, and fortunately Microsoft has provided a nice script that performs it for you. Otherwise, it would be quite a task.
It’s important to note that you must add the default domain your SharePoint environment is currently setup in. Otherwise, you won’t even be able to do lookups in it! (Found that out the hard way)
Instructions: Open Notepad or your favorite text editor, copy and paste the code below into the file, and save it as a .ps1 file. Open the SharePoint PowerShell command window as an Administrator, and an account with farm level access, change the directory (cd C:\YourDirectory, etc.) to the place you saved the code below (as a .ps1 file), type out .\YourPowerShellScript.ps1 and hit enter.
*I provide this as is, with no guarantees it will resolve your issues. And if you muck up your environment, it’s not my fault. 🙂 Obviously you should perform this on a dev or test environment first before attempting it in production. Good luck!*
Since I had to piece together how to accomplish the migration of a host-named site collection (HNSC) I had already setup in SharePoint 2013, from one farm to another, I figured I would outline exactly how to do it. In my case, I needed the HNSC to be in its own content database, I’m targeting a particular web app with the HNSC as opposed to using a wildcard web app to handle the hostnames, and all of this is assuming you have your rights setup to be able to carry out all of this; SQL, SharePoint farm account and otherwise. With that said…
For future reference. This came in very handy after I turned on Google 2-step verification. Originally found here: http://passion4high-tech.blogspot.com/2013/03/postfix-sasl-authentication-failed-with.html
————————————–
If you configure your Google account for extra security to use the 2-step verification, then some applications which work outside the browser might not be compatible with 2-step verification and cannot ask for verification codes.
Something like:
SASL authentication failed; server smtp.gmail.com said: Application-specific password required.
For some reason I found this rule to be difficult but finally got it to work thanks to the internets. This is the only rule that worked within the NGINX configuration to get only the root URL to redirect to (in my case) a non-SSL location. Here’s the section:
server {
(..)
location / {
rewrite ^(/)$ http://www.domain.com/ permanent;
}
}http://stackoverflow.com/questions/9336261/nginx-rewrite-only-when-root-domain
Recently I embarked on finding the optimal NGINX SSL security settings and stumbled across this post: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
For a number of reasons, it recommends disabling SSLv3 (as a result of its insecurity), settings AES256 as the standard cipher to utilize and a couple of other things that can prevent attacks. Good stuff to tighten up security on an NGINX SSL implementation.
Update 8/3/2015:
The speed has now been bumped up to 300 mbps up/down; so fast now, I need a new internal router/firewall 🙂
——————————————————————-
After events that occurred with AT&T on the technical and customer service sides back when I first moved into my new house, I wasn’t quite sure what to expect with changing over, once again, to new service. However, after all of the frustration and mind-boggling breakdowns in order processing and account bungling from a few months ago, this has been worth the wait.
I had a failure recently when trying to compile ModSecurity as a standalone module for use within NGINX that seemed to be pretty consistent with what others were experiencing, from the limited number of sites that seemed to have information on this particular problem. I knew it was possible to set this up, but I also knew I was missing something.
After scanning the internet for a solution and getting some pointers from Ryan Barnett at Trustwave’s SpiderLabs, I finally found what I was looking for to get this to work.
I went through this http://www.modsecurity.org/projects/modsecurity/nginx/ and kept receiving this error:
configure: looking for Apache module support via DSO through APXS
configure: error: couldn’t find APXS
… even after I went through and made sure I had all these prerequisites installed (thanks for pointing me here Ryan): https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Prerequisites.
So then I was stuck, until I just searched why anyone gets this error at all and discovered this: http://knowledge-republic.com/CRM/2981/ubuntu/ubuntu-missing-apxs-fo-compile-apache-module/
In addition to the prerequisites noted in the last link, you must install apache2-prefork-dev instead of, or in addition to, apache2-threaded-dev in order to utilize the APXS extension tool.
Once I did that, I compiled the module successfully and was able to continue on with the rest.
I’m still waiting for an easy-to-add ModSecurity module for NGINX that I can just pull down using apt-get. 😉
Powered by WordPress & Theme by Anders Norén