Anmelden
 
HomeLibraryDownloadsSupportWebcasts & EventsCommunityForenBlogs
Ressourcen für IT-Professionals >
> 
> 
How do I setup SharePoint 2010 to authenticate domain users within an active directory setup?

Отвечено How do I setup SharePoint 2010 to authenticate domain users within an active directory setup?

  • Mittwoch, 25. April 2012 09:49
     
     
    Anmelden
    0

    Hi,

    I have an installation of SharePoint Server 2010 on a server running windows server 2008 with SharePoint SP1 and the latest CU hotfix installed. For some reason or another the only way I can get users within AD to authenticate onto my sharepoint frontend is to place them within the local administrators group on the server? Within SharePoint (using a local admin account) I can assign all the AD users and groups to SharePoint groups with correct permissions but once these users attempt to browse to the SP url they cannot authenticate? I have also assigned the "NT Authority\authenticated users" group correct read permissions within SharePoint. Do I have to setup a User Profile Service within central administration or am I missing something?

    Thanks.

     

Alle Antworten

  • Mittwoch, 25. April 2012 10:04
     
     
    Anmelden
    0
    What is the message you are receiving when you are trying to log in to SharePoint using a domain account? Is it the Access Denied page?

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog: SharePoint Related
    E-mail: Nico Martens

     
  • Mittwoch, 25. April 2012 10:14
     
     
    Anmelden
    0

    You do not need the User Profile Service for users to access SharePoint sites in your environment.  Did you follow a guide when you installed your farm?  either something appears to be wrong with the accounts used during this process or theres more restrictive elements in place such as policies which are preventing the correct access to your farm. 

    Some more information would be useful, for example is this a multi-server farm environment?  Are you using Kerberos, as this could be an issue if the SPN's etc are not correctly configured.  I'm also at this point making the assumption that you're trying to connect to a totally out of the box site without custom code.

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Mittwoch, 25. April 2012 10:46
     
     
    Anmelden
    0

    Nico,

    After three login attempts I am confronted with a blank screen, i.e. no access denied page.

    Martin.

     
  • Mittwoch, 25. April 2012 11:01
     
     
    Anmelden
    0

    Paul,

    I used the AutoSPInstaller:

    http://autospinstaller.codeplex.com/

    How would I check policies that may be preventing the correct access to my farm? The reason I thought a user profile service was required is due to my setup involving a separate active directory server to authenticate users into sharepoint through windows authentication (domain\username). However, it did seem strange that I could see the AD users and groups within sharepoint without this user profile service configured, making me think this service shouldn't be required like you say. But when I assign them appropriate permissions to the sharepoint site they can only authenticate to view the site if they are within the local administrators group on the server?

    My environment is: One frontend web server running sharepoint and two database servers for the SharePoint content databases and backup. I am not using Kerberos. I have configured my sharepoint site using IIS. I have installed a .wsp file containing a custom master page but that is all the customisations made.

    Thanks.

     
  • Mittwoch, 25. April 2012 11:05
     
     
    Anmelden
    0
    Are you trying this from a workstation in the domain or on the server itself?

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Mittwoch, 25. April 2012 11:07
     
     
    Anmelden
    0
    On the server itself.
     
  • Mittwoch, 25. April 2012 11:09
     
     
    Anmelden
    0
    Have you disabled the loop back check? http://support.microsoft.com/kb/896861

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Mittwoch, 25. April 2012 11:14
     
     
    Anmelden
    0

    But my users have been trying from their local machines and not been able to authenticate. When they try the local admin account from their machines they authenticate fine?

    Thanks.

     
  • Mittwoch, 25. April 2012 11:20
     
     
    Anmelden
    0
    This has now been disabled but I still can't seem to authenticate :(
     
  • Mittwoch, 25. April 2012 11:30
     
     
    Anmelden
    0

    Hi,

    So to summarize:

    - You are trying to authenticate AD users from the server itself. Are you using NTLM or Kerberos authentication?

    - You disabled the LoopbackCheck by creating a Dword (32-bit): DisableLoopbackCheck (and set it to 1) in the following location:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog: SharePoint Related
    E-mail: Nico Martens

     
  • Mittwoch, 25. April 2012 11:34
     
     
    Anmelden
    0

    Nico,

    Integrated Windows Authentication using NTLM. Yes, I have created the Dword.

    Thanks.

     
  • Mittwoch, 25. April 2012 11:35
     
     
    Anmelden
    0

    Should I go ahead and configure the user profile service and sync service to see if that then allows my users to authenticate using their ad domain\username credentials?

    Thanks.

     
  • Mittwoch, 25. April 2012 11:39
     
     
    Anmelden
    0

    This will not help your authentication problem.

    User Profile Service Application is not used for authenticating.

    This is used for the MySite functionality including Tagging and notes and importing your properties from AD to SharePoint, but not for authentication.

    How did you set up your SharePoint farm. Did you use domain service accounts?

    Domain\SP_farm
    Domain\SP_admin

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog: SharePoint Related
    E-mail: Nico Martens

     
  • Mittwoch, 25. April 2012 12:00
     
     
    Anmelden
    0
    Yes, I used domain service accounts as you mentioned above.
     
  • Mittwoch, 25. April 2012 12:05
     
     
    Anmelden
    0

    Please check your Event Viewer (Windows Logs/System).

    Filter the Current log for event ID 6037. Does it show anything?

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog: SharePoint Related
    E-mail: Nico Martens

     
  • Mittwoch, 25. April 2012 12:12
     
     
    Anmelden
    0
    Nothing under that ID Nico :(
     
  • Mittwoch, 25. April 2012 12:17
     
     
    Anmelden
    0

    Could you use ULS Viewer during the logging in to SharePoint, this might identify the problem, or give us a direction to look in.

    For a description of how to use it, check http://www.maartenpeeters.nl/MyBlog/?p=115

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog: SharePoint Related
    E-mail: Nico Martens

     
  • Mittwoch, 25. April 2012 12:26
     
     
    Anmelden
    0

    Nothing really in the logs Nico...


     
  • Mittwoch, 25. April 2012 12:28
     
     
    Anmelden
    0
    Can you double check the Permission Policy for your web application? http://technet.microsoft.com/en-us/library/ff608071.aspx

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Mittwoch, 25. April 2012 12:38
     
     
    Anmelden
    0

    Paul,

    Under the web app I have added my test user (user account not within the local administrators group on the server) to the user policy with full control under all zones but still I cannot authenticate with this account.

    Thanks.

     
  • Mittwoch, 25. April 2012 12:44
     
     
    Anmelden
    0
    I have also now created a new permission level with full control and appended this level to my test user but still no authentication :(
     
  • Mittwoch, 25. April 2012 15:08
     
     
    Anmelden
    0

    Paul/Nico,

    I have just noticed the following within the ULS Viewer. What could be causing the accessdenied.aspx page call? This page doesn't seem to show within the browser either?...

     
  • Donnerstag, 26. April 2012 05:28
     
     
    Anmelden
    0

    Hi,

    Have you set up the caching accounts? (Superuser and superreader accounts)

    If they are set up incorrectly, you might get a similar error.

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog: SharePoint Related
    E-mail: Nico Martens

     
  • Donnerstag, 26. April 2012 08:22
     
     
    Anmelden
    0

    How do I setup these accounts within SharePoint? Is there a best practice?

    Thanks.

     
  • Donnerstag, 26. April 2012 08:30
     
     
    Anmelden
    0

    If you have never set it up, this shouldn't be the problem you are seeing.
    I thought maybe you (or someone else that has been working with SharePoint) might have set it up.

    http://www.sharepointchick.com/archive/2010/10/06/resolving-the-super-user-account-utilized-by-the-cache-is.aspx

    This link contains the way to configure these caching accounts for Sharepoint 2010.

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    My Blog
    E-mail me

     
  • Donnerstag, 26. April 2012 08:41
     
     
    Anmelden
    0

    This isn't the error I am receiving in the event log so I doubt this is required....what a nightmare - nothing seems to work :( Why do users/groups have to be added to the local admin group?...urrghh!

    Thanks.

     
  • Donnerstag, 26. April 2012 09:36
     
     
    Anmelden
    0

    Actually Nico,

    You could be on the right track as the AutoSPInstaller does include configuration for these accounts.

    ASP-NetScotland, In the AutoSPInstallerInput.xml have you configured the section below?  If so have you also provisioned the accounts in AD?

    - <ObjectCacheAccounts>
      <SuperUser>DOMAIN\SP_CacheSuperUser</SuperUser>
      <SuperReader>DOMAIN\SP_CacheSuperReader</SuperReader>
    </ObjectCacheAccounts>

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Donnerstag, 26. April 2012 09:39
     
      Enthält Code
    Anmelden
    0

    Thank you Paul for that info, that is helpful.

    For the web application that is failing, please perform the following:

    $webapp = Get-SPWebApplication "URL for web application"
$webapp.properties["portalsuperuseraccount"] = $null
$webapp.properties["portalsuperreaderaccount"] = $null
$webapp.Update()

    This will remove these accounts for the web application.

    If it will not help, I can help you configure the caching accounts correctly.

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    My Blog
    E-mail me

     
  • Donnerstag, 26. April 2012 10:20
     
     
    Anmelden
    0

    Nico,

    Do you want me to run your code in powershell?

    Thanks.

     
  • Donnerstag, 26. April 2012 10:24
     
     
    Anmelden
    0

    Paul,

    The below accounts were configured...

    <ObjectCacheAccounts>
                <SuperUser>domain\sps_cacheadmin</SuperUser>
                <SuperReader>domain\sps_cachereader</SuperReader>
    </ObjectCacheAccounts>

    Thanks.


     
  • Donnerstag, 26. April 2012 10:28
     
     
    Anmelden
    0
    These accounts have not been provisioned in AD.
     
  • Donnerstag, 26. April 2012 10:42
     
     
    Anmelden
    0
    I would get them provisioned, they only need to be standard user accounts.

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Donnerstag, 26. April 2012 10:48
     
     
    Anmelden
    0

    Am i right in saying that due to these accounts not being provisioned (by this you mean just add them to AD I presume, I don't have to reference them anywhere?) the superuser and superreader are blank therefore all domain users are not able to authenticate into the site?

    Thanks.

     
  • Donnerstag, 26. April 2012 10:51
     
     
    Anmelden
    0
    I think it's more the point that if you provision them and your farm has been configured to use them and this doesn't solve your issue it's another thing we can rule out as part of the problem.  It could of course solve everything.

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Donnerstag, 26. April 2012 10:54
     
     
    Anmelden
    0

    Paul,

    Below is how I installed SharePoint. Have I missed anything?...

    http://www.kemponline.co.uk/archive/2011/07/04/autospinstaller-script.aspx

    Thanks.

     
  • Donnerstag, 26. April 2012 11:00
     
      Enthält Code
    Anmelden
    0

    Hi,

    If you configured the caching accounts without provisioning them in AD and giving them the sufficient permissions, you will get this error.

    SharePoint uses these accounts to cache the SharePoint page, so when a regular user logs in to the site, it will get the data retrieved by these accounts.
    If they are not provisioned correctly, you will not see your SharePoint page.

    Please run the script I provided in the SharePoint Management Shell (as administrator).

    $webapp = Get-SPWebApplication "URL for web application"
$webapp.properties["portalsuperuseraccount"] = $null
$webapp.properties["portalsuperreaderaccount"] = $null
$webapp.Update()

    Make sure you change the bold part to reflect your environment.

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    My Blog
    E-mail me

     
  • Donnerstag, 26. April 2012 11:01
     
     Beantwortet
    Anmelden
    0

    Striclty speaking you haven't missed anything based on that blog post.  The problem is the blog post instructs you to download the script from CodePlex which is fine but since the blog post has been written, the script has changed a couple of times.

    The script now configures your farm to use the cache reader accounts but the blog post doesn't mention them.

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.


     
  • Donnerstag, 26. April 2012 11:04
     
     
    Anmelden
    0

    Nico,

    If I run your script should I then be able to authenticate or do I still need to provision those accounts in AD? i.e. is this a workaround?

    Thanks.

     
  • Donnerstag, 26. April 2012 11:05
     
     
    Anmelden
    0

    If you run that, you will be able to authenticate (if this is the problem).

    It will remove the superuser and superreader account for your web application.

    If it works after removing them, we know where the issue is, and we can help you fix it.

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog
    E-mail


    • Bearbeitet Nico Martens Donnerstag, 26. April 2012 11:06
    •  
     
  • Donnerstag, 26. April 2012 11:08
     
     
    Anmelden
    0

    Nico,

    Paul mentioned that these accounts only need to be standard user accounts, is this the case? Just due to you mentioning they have to have sufficient permissions.

    Thanks.

     
  • Donnerstag, 26. April 2012 11:11
     
     
    Anmelden
    0

    They should be assigned permissions (in SharePoint). What Paul means is they do not need permissions outside SharePoint.

    The domain\sps_cacheadmin should have Full Control on the web application

    The domain\sps_cachereader should have Full Read on the web application.

    To do this, go to Central Administration -> Application Management. Select the Web Application and click "User Policy".

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
    Blog
    E-mail

     
  • Donnerstag, 26. April 2012 12:16
     
     
    Anmelden
    0

    Ok, I'll run your script and let you know.

    Thanks again.

     
  • Donnerstag, 26. April 2012 12:30
     
     
    Anmelden
    0
    I've just noticed that the sp_cachereader and sp_cacheadmin accounts are referenced within the web apps user policy with sufficient permissions and are also provisioned in AD...damn! :( Hitting brickwalls here!
     
  • Donnerstag, 26. April 2012 12:38
     
     
    Anmelden
    0
    Ok, so we know that if you add users to the local administrators group on your SharePoint box they can successfully get access.  Ignoring any user accounts, what other accounts do you have in the local admin group and can you check these are not disabled or locked out in AD?

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Donnerstag, 26. April 2012 12:47
     
      Enthält Code
    Anmelden
    0

    I still think it is related to the cache users.

    To verify, could you run the following:

    $webapp = Get-SPWebApplication
$webapp.properties["portalsuperuseraccount"]
$webapp.properties["portalsuperreaderaccount"]

    This will show you the configured caching accounts.
    Let me know what it shows

    Kind regards,

    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
        

     
  • Donnerstag, 26. April 2012 13:53
     
     
    Anmelden
    0

    Nico,

    After adding the SP snapin for powershell through the below code:

    Add-PSSnapIn "Microsoft.SharePoint.PowerShell" -EA 0

    Line 1 of your code ran but I received the error "Cannot index into a null array" when I ran line 2?

    Thanks.

     
  • Donnerstag, 26. April 2012 13:57
     
     
    Anmelden
    0

    Paul,

    Yes, the local admin group grants them authentication to the sharepoint site, if they are not members they cannot authenticate.

    The other accounts within the local admin group are:

    DOMAIN\Domain Admins
    DOMAIN\sp_AppPool
    DOMAIN\sp_farm
    DOMAIN\sp_MySite
    DOMAIN\SP_Search
    DOMAIN\SP_Service

    I can confirm that these are not disabled or locked out in AD.

    Thanks.

     
  • Donnerstag, 26. April 2012 14:08
     
     
    Anmelden
    0

    I know this might be a pain, but just incase anything has changed, it's worth confirming the rights the IIS_Users group on the machine has.  This group is used for impersonation.

    http://support.microsoft.com/kb/981949

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Donnerstag, 26. April 2012 14:19
     
     
    Anmelden
    0

    Paul,

    The group is actually called "IIS_IUSRS" and I can't see the permissions attached to this group under the server manager. The properties only show a general tab at which the below accounts are members:

    DOMAIN\Domain Admins

    DOMAIN\sp_AppPool
    DOMAIN\sp_farm
    DOMAIN\sp_MySite

    NT Authority\Local Service

    Thanks.

     
  • Freitag, 27. April 2012 06:25
     
      Enthält Code
    Anmelden
    0

    Sorry, i forgot the url part in the above code:

    $webapp = Get-SPWebApplication "URL"
$webapp.properties["portalsuperuseraccount"]
$webapp.properties["portalsuperreaderaccount"]


    Nico Martens - MCTS, MCITP
    SharePoint 2010 Infrastructure Consultant
        

     
  • Montag, 30. April 2012 09:31
     
     
    Anmelden
    0

    Nico,

    After running your above code I can confirm that the below accounts have been set up:

    DOMAIN\sp_cacheadmin

    DOMAIN\sp_cachereader

    I think all this is pointing at a bad installation of SharePoint, would you agree? I'm going to re-install by following the below guidelines:

    http://blogs.msdn.com/b/mtc/archive/2009/12/08/how-to-setup-sharepoint-2010-public-beta-user-profile-synchronization-with-active-directory-on-windows-server-2008-r2.aspx

    ....unless you can provide any other fixes?

    Thanks.

     
  • Montag, 30. April 2012 09:37
     
     
    Anmelden
    0

    Hi,

    Personally If you're removing and re-installing, I would familiarise myself with the information available from a solid resource like Technet.  http://technet.microsoft.com/en-us/library/cc262957.aspx

    The link you've chosen to follow is from 2009 and based around the pre-release beta.

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Dienstag, 1. Mai 2012 15:54
     
     
    Anmelden
    0

    Any input on the below resource guys...

    http://technet.microsoft.com/en-us/library/cc738653%28v=ws.10%29.aspx

    Due to not having access to the AD server I have requested this to be actioned but just wondered what your thoughts are on this?

    Thanks.

     
  • Dienstag, 1. Mai 2012 19:47
     
     
    Anmelden
    0
    The article you've attached is related to Windows 2003, is that still applicable to your environment?

    Paul Turner http://redmanta.co.uk/blog Twitter: @RedMantaUK MCTS:WSS,MOSS,2010 MCITP:2010.
    Please remember to click "Propose As Answer" if a post solves your problem or "Vote As Helpful" if it was useful.

     
  • Mittwoch, 2. Mai 2012 05:32
     
     
    Anmelden
    0

    I doubt that is it, I've never had to change that setting on my installation. What you may want to try is see if you can get ahold of a domain admin or something similar account and change your sharepoint site app pool to run as that account. It almost sounds like your site/identity cannot access active directory to get the user information. When you add them local it can find the user.  

    What happens if you add a user to another group on the server like just Users? 

     
  • Mittwoch, 2. Mai 2012 08:50
     
     
    Anmelden
    0

    Turismon,

    Yes, when I add the users to the local administrators group, and only the local administrators group, on the sharepoint frontend server they can authenticate.

    I tried the "allowed to authenticate" setting but that didn't solve the issue :(

    I will try the site app change to see if that works...

    Thanks.

     
  • Donnerstag, 3. Mai 2012 09:50
     
     
    Anmelden
    0

    Turismon,

    After changing my site app pool to run as a domain admin from the AD server the issue still remained. I have a domain admin user also, after making him a domain admin from the AD server he could authenticate. Summary: Individual users have to be a member of the local admin group or a domain admin on the AD server in order to authenticate. STRANGE!

    Thanks.