SharePoint ACLs/Group resolution in a Kerberized environment

Introduction

This document discusses configuration of the Google Search Appliance against a SharePoint server utilizing access control lists(ACLs) and groups leveraging commonly integrated technologies such as Active Directory and Kerberos. It should be considered as a primer for familiarizing oneself with the configuration and setup of the GSA in such an environment. Please refer to the below URL for the official documentation for the Google Connector for SharePoint.

Scope

The scope of this document is limited to and focused on integration of the GSA into the above environment and is not overtly concerned with the initial setup of SharePoint and Active Directory. It also covers possible use case scenarios including log snippets which explain some of the relevant internal workings of the connector.

Requirements

This document has been tested with the following components:

  1. Windows Server 2007
  2. IIS 7.0
  3. SharePoint 2010
  4. GSA 6.14.0.G.28
  5. GSA Onboard Connector Manager 2.8.4
  6. GSARKS 2.8.2

The following components are taken to be already configured.

  1. SharePoint test site. (Required)
  2. GSA with Kerberos Authentication. (Optional)

Active Directory

Integral to this document is user and group access, before proceeding we need to create various accounts which will be used for our test scenarios. For the test cases presented here the following users and groups have been created in Active Directory.

  1. kerbadmin - administrator account for our kerberized SharePoint testsite.
  2. user_group - user group for accessing SharePoint.
  3. gsa1 - end user account which is a member of user_group above.

 

 

SharePoint Test Site

Our SharePoint testsite needs to be setup to authenticate correctly with Windows for the GSA to be able to do the necessary user/permission lookups. For this document we are using Kerberos authentication to provide seamless access.

For our testing purposes we are using "Windows Authentication Type". If you are setting up a new site, you will be prompted for this during setup otherwise it is configurable in SharePoint Central Administration under - Central Administration > Application Management > Authentication Providers > Edit Authentication

 

As the above text states since we are using Kerberos we need to set the Application Pool to be "Network Service or Special Configuration". NetworkService is the default configuration in the built-in account however since we are using a separate application pool for our SharePoint site we need to set it to a special configuration. In this case we will set it to be the Active Directory account which we are using to administer our SharePoint test site. In IIS Manager navigate to the Application Pools location, for example.SHAREPOINT\Application Pools, right click the SharePoint testsite pool and select Advanced Settings.

NOTE: The "pool account" is actually labeled as "Identity" under the Process Model heading in the Advanced Settings. Changing this to "Custom Account" and entering the full Active Directory user(DOMAIN\kerbadmin) will allow us to use the test site for kerberized user/group authentication.

 

Now that we have configured Central Administration ensure that our admin account is setup, add the administration account kerbadmin to SharePoint with full access. Then create a test page, for this article I have added a test page called "GoogleWiki".

Onboard Connector Configuration

Following this we can proceed to integrating these with the GSA connector, let’s dive straight in and test the configuration against Active Directory. Under Google Search Appliance > Connector Administration > Connector Managers, Create new connector manager eg.

NOTE: You can download the connector manager logs from this screen!

 

In the Connectors tab, create a new connector (we will call it kerb_sp_acl) with "Type" "sharepoint-connector" from the drop down menu and click "Get Configuration Form" to complete.

Below is the sample configuration used for this document.

 

 

 

ACL information is sent in the Feed so policy verification at serve time may take some time to take effect, permissions changes made in SharePoint will not have effect until a new feed has been pushed. There are also two types of Authorization presented in the above form,

Authorization by Head Request and Authorization by Connector. It’s important to note that selecting Authorization by Head request will create a metadata feed, while Authorization by Connector will generate a content feed.

 

If your connector configuration is correct it will save successfully and return you to the previous screen. A successful connection or bind will yield output as below in the Google Connector log file (available from the connector manager screen).

 

Apr 19, 2012 8:16:37 PM [Config kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection <init>
INFO: LdapConnectionSettings [authType=Simple, baseDN=DC=domain,DC=com, connectMethod=Standard, hostname=test.domain.com, password=####, port=389, serverType=ACTIVE_DIRECTORY, userName=kerbadmin, domainName =domain.com ]
Apr 19, 2012 8:16:37 PM [Config kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection configureLdapEnvironment
INFO: Using simple authentication.
Apr 19, 2012 8:16:37 PM [Config kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection makeLdapUrl
INFO: Complete LDAP URL : ldap://test.domain.com:389
Apr 19, 2012 8:16:37 PM [Config kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection createContext
INFO: Sucessfully created an Initial LDAP context
Apr 19, 2012 8:16:37 PM [Config kerb_sp_acl] com.google.enterprise.connector.sharepoint.client.SharePointClientContext checkSharePointType
INFO: SharePoint Version : 12.0.0.6545
Apr 19, 2012 8:16:37 PM [Change kerb_sp_acl] com.google.enterprise.connector.sharepoint.spiimpl.SharePointConnector login
INFO: Connector login()
Apr 19, 2012 8:16:37 PM [Change kerb_sp_acl] com.google.enterprise.connector.sharepoint.spiimpl.SharePointSession <init>
INFO: SharePointSession
(SharePointConnector inConnector,SharePointClientContext inSharePointClientContext)
Apr 19, 2012 8:16:37 PM [Change kerb_sp_acl] com.google.enterprise.connector.sharepoint.spiimpl.SharePointSession getAuthorizationManager
INFO: getAuthorizationManager()

 

 

The key lines here are the Info Statements , for example "INFO: Sucessfully created an Initial LDAP context" , indicates we have successfully connected to Active Directory (LDAP). If this fails due to network or other misconfiguration instead at this point we will observe the following.

 

Apr 19, 2012 8:15:14 PM [Config kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection createContext
WARNING: Could not obtain an initial context to query LDAP (Active Directory) due to a communication failure.
javax.naming.CommunicationException: test.domain.com:389 [Root exception is java.net.UnknownHostException: test.domain.com]
	at com.sun.jndi.ldap.Connection.(Connection.java:223)
	at com.sun.jndi.ldap.LdapClient.(LdapClient.java:136)
	...

 

As the connector proceeds, the info statements read more verbose information eventually starting to pick up documents and completing the traversal process.

 

INFO: Traversal returned 13 documents discovered in the current batch traversal.
…
INFO: Connector completed a full crawl cycle traversing all the known site collections at time : 2012-04-19 21:27:00 PDT

 

At this stage a feed "in progress" will then be created under Google Search Appliance > Crawl and Index > Feeds, once complete the newly indexed content will appear underGoogle Search Appliance > Status and Reports > Crawl Diagnostics. The fed ACL information is displayed for each indexed page, as below for example.

 

This page has the following Access Control List (ACL):

  1. Permitted Users
  1. Permitted Groups
  1. kerbadmin
  2. local service
  3. network service
  1. [http://sharepoint.domain.com:14357][GSSiteCollectionAdministrator]
  2. [http://sharepoint.domain.com:14357]testsite Members
  3. [http://sharepoint.domain.com:14357]testsite Owners
  4. [http://sharepoint.domain.com:14357]testsite Visitors

 

These permitted user and group ACLs are used at serve time by the GSA to authorize documents. Every document queried in a search will have its ACL string compared against the looked up user/group string for the requesting user. These need to match for the document to be sucsessfully returned.

The highlighted accounts above will be used as examples in the scenarios in the next section on Serving Connector Results.

 

 

 

Serving Results

Now that we have crawled our SharePoint site, we need to leverage those ACLs for returning results. Navigate to Google Search Appliance > Serving > Universal Login Auth Mechanisms > Connectorsand fill in the form creating a new mechanism name for the connector we configured in the previous step. Example below.

By selecting "Perform group lookup only", we are telling the connector to only lookup the groups and not to perform any authentication. Instead authentication will be handled by kerberos which has been previously configured on the GSA under Google Search Appliance > Serving > Universal Login Auth Mechanisms > Kerberos,

Scenario 1 : Serving Results to a Permitted User

To ensure we can actually retrieve results correctly, we will start by using the same user to perform a secure search. We’ve already added the user(kerbadmin) as a user in SharePoint and in Active Directory, furthermore we are logged into a kerberized environment as that user. Navigate to the search page, select "public and secure search" and search for "googleconnector". Google connector results should be returned. As we have seen user kerbadmin is a Permitted user, as such group information is not necessary, we simply need to verify the user ID against the one listed in the ACL. For the purposes of understanding the logs however, we will look at the LDAP group results also. First the connector logs, the logs are quite verbose, but lets take a look at the important segments.

 

- User name and domain lookup

INFO: Received authN request for Username [ kerbadmin ], domain [ DOMAIN.COM ]. 
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.spiimpl.SharePointAuthenticationManager authenticate

 

- Request for all Groups for that User via Active Directory(LDAP).

INFO: Attempting group resolution for user : kerbadmin
com.google.enterprise.connector.sharepoint.ldap.UserGroupsService getAllGroupsForSearchUser
INFO: The LDAP cache is not yet initialized and hence querying LDAP and User Data Store directly.
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService getAllLdapGroups
INFO: Quering LDAP directory server to fetch all direct groups for the search user: kerbadmin
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection 
INFO: LdapConnectionSettings [authType=Simple, baseDN=DC=domain,DC=com, connectMethod=Standard, hostname=test.domain.com, password=####, port=389, serverType=ACTIVE_DIRECTORY, userName=kerbadmin, domainName =domain.com ]
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection configureLdapEnvironment
INFO: Using simple authentication.
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection makeLdapUrl
INFO: Complete LDAP URL : ldap://test.domain.com:389
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService$LdapConnection createContext
INFO: Sucessfully created an Initial LDAP context

 

 

- Active Directory returns the LDAP group information for user kerbadmin.

INFO: [ kerbadmin ] is a direct member of 7 groups : [CN=EnterpriseSupportJP,CN=Users,DC=domain,DC=com, CN=Administrators,CN=Builtin,DC=domain,DC=com, CN=Domain Admins,CN=Users,DC=domain,DC=com, CN=Enterprise Admins,CN=Users,DC=domain,DC=com, CN=Remote Desktop Users,CN=Builtin,DC=domain,DC=com, CN=Schema Admins,CN=Users,DC=domain,DC=com, CN=Group Policy Creator Owners,CN=Users,DC=domain,DC=com]
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService getAllParentGroups
INFO: Parent groups for the group [CN=EnterpriseSupportJP,CN=Users,DC=domain,DC=com] : [CN=Administrators,CN=Builtin,DC=domain,DC=com, CN=EnterpriseSupport,CN=Users,DC=domain,DC=com]

 

- This then gets expanded to the full list of membership, ie. inherited groups.

INFO: [ kerbadmin ] is a direct or indirect member of 10 groups
Apr 20, 2012 1:29:48 AM [AuthN kerbadmin kerb_sp_acl] com.google.enterprise.connector.sharepoint.ldap.UserGroupsService getAllADGroupsAndSPGroupsForSearchUser
INFO: Quering User data store with the AD groups :[DOMAIN.COM\remote desktop users, DOMAIN.COM\domain admins, DOMAIN.COM\denied rodc password replication group, DOMAIN.COM\schema admins, DOMAIN.COM\administrators, DOMAIN.COM\group policy creator owners, DOMAIN.COM\enterprise admins] and search user [kerbadmin]
Now we have all the group information that is required and Authorization is handed off to the GSA (since we configured above for group lookup only). This leads us onto the the security manager log, which shows the below successful kerberos authentication, this is as standard, group information can also be seen here.

NOTE: For debugging purposes, it's useful to observe the Session ID, which is consistent between authorization and security manager logs.

NOTE: Security Manager logs can be downloaded at Google Search Appliance > Serving > Universal Login

add to http://google.com/enterprise/gsa/security-manager/my_connector_mech: {Verification: status=VERIFIED; expires at 2012-05-10T20:46:53.102-07:00; credentials {groups: "DOMAIN\\remote desktop users", "DOMAIN\\enterprise admins", "DOMAIN\\denied rodc password replication group", "DOMAIN\\schema admins", "DOMAIN\\group policy creator owners", "DOMAIN\\domain admins", "DOMAIN\\administrators", "[http://sharepoint.domain.com:14357][GSSiteCollectionAdministrator]"}}
Returns Sucessful!
120510 20:26:53.165:I 33 [.authncontroller.AuthnController.maybeRetryGatheringCredentials] sid 1affe82077fc21ae62709564dcf4ff46: Credentials verified.
120510 20:26:53.165:I 33 [.authncontroller.AuthnController.updateOutgoingCookies] sid 1affe82077fc21ae62709564dcf4ff46: Outgoing cookies to user agent: (none)
120510 20:26:53.165:I 33 [.authncontroller.AuthnController.authenticate] sid 1affe82077fc21ae62709564dcf4ff46: Leaving authentication controller in state AUTHENTICATING with result SUCCESSFUL

 

And finally in the authorization log the policy is permitted.

NOTE: Authorization logs can be downloaded at Google Search Appliance > Serving > Access Control

[GSA_ADMIN_LOG] Authorization results for session: 1affe82077fc21ae62709564dcf4ff46: decision [2/14]
PERMIT by POLICY for URL 

 

 

Scenario 2 : Serving Results to a user in a SharePoint Permitted Group

 

SharePoint by default has a visitors group, this is a standard group with Read only access. If we look at our test document "GoogleWiki", and access the manage permissionspanel, by default it should show group Visitors with read access.

 

Adding a user(gsa2) to this group ‘testsite visitors’, will grant them read access.

 

 

Back under Google Search Appliance > Connector Administration > Connectors, Click reset on the connector to re-feed the ACL information. Re-login to Windows as the new user"gsa2" and attempt to perform a new search for "google wiki", a result should be returned.

In the google connectors log we can see the SharePoint group information being pulled for this user.

INFO: Group resolution service returned following groups for the search user: gsa2
[DOMAIN\remote desktop users, [http://sharepoint.domain.com:14357]testsite Visitors]

 

Remember also that the GSA has the above ACL listed in crawl diagnostics. [http://sharepoint.domain.com:14357]testsite Members

 

Security manager log shows the user being verified, and also the same SharePoint group membership. Finally authenticating with result successful.

 add to http://google.com/enterprise/gsa/security-manager/kerb: {Verification: status=VERIFIED; expires at 2012-05-11T01:17:05.501-07:00; credentials {principal: "gsa2@DOMAIN.COM"}}
...
120511 01:12:05.597:I 33 [.authncontroller.AuthnSession.updateSessionState] sid 4c1f42f20eb16a5f52bb84a964246b1a: Modify session state:
  add to http://google.com/enterprise/gsa/security-manager/my_connector_mech: {Verification: status=VERIFIED; expires at 2012-05-11T01:32:05.577-07:00; credentials {groups: "DOMAIN\\remote desktop users", "[http://sharepoint.domain.com:14357]"testsite Visitors, "DOMAIN\\gsa_crawlers"}}
120511 01:12:05.597:I 33 [.authncontroller.AuthnController.maybeRetryGatheringCredentials] sid 4c1f42f20eb16a5f52bb84a964246b1a:: Credentials verified.
120511 01:12:05.597:I 33 [.authncontroller.AuthnController.updateOutgoingCookies] sid 4c1f42f20eb16a5f52bb84a964246b1a:: Outgoing cookies to user agent: (none)
120511 01:12:05.597:I 33 [.authncontroller.AuthnController.authenticate] sid 4c1f42f20eb16a5f52bb84a964246b1a:: Leaving authentication controller in state AUTHENTICATING with result SUCCESSFUL

 

The Authorization log then returns Permit by Policy.

[GSA_ADMIN_LOG] This batch of requests completed.  Elapsed time(after cache/ACL check): 0 ms session id: 4c1f42f20eb16a5f52bb84a964246b1a 
120511 00:56:36.127:I 10254 [com.google.enterprise.authzchecker.AuthzRequestProcessor.logResults] [[GSA_ADMIN_LOG] Authorization results for session: 4c1f42f20eb16a5f52bb84a964246b1a decision [1/2] PERMIT by POLICY for URL googleconnector://kerb_sp_acl.localhost/doc?docid=http://sharepoint.domain.com:14357/Shared%20Documents/Forms/AllItems.aspx%7C2
, [GSA_ADMIN_LOG] Authorization results for session: 4c1f42f20eb16a5f52bb84a964246b1a: decision [2/2] PERMIT by POLICY for URL googleconnector://kerb_sp_acl.localhost/doc?docid=http://sharepoint.domain.com:14357/UserLibrary/Forms/AllItems.aspx%7C2]

 

 

Scenario 3 : Serving Results to a user in an Active Directory Permitted Group

 

Now let’s try the same thing, but using an AD group, add the group DOMAIN\user_group to the SharePoint site as follows, under Site Settings > Permissions

 

And configure it with ‘Read - Can view only’ Permissions.

Finally for our test Document "GoogleWiki", ensure permissions are set to read only.

NOTE: Specifying document specific permissions in SharePoint overrides any inherited permissions.

 

Now that SharePoint is configured, back on the GSA, click reset on the connector to refeed the contents and ACL’s again. Google Search Appliance > Status and Reports > Crawl Diagnostics, Find and select the link for the new page added to see the uploaded ACL permissions.

For instance, it will show..

All hosts > googleconnector:/ / kerb_sp_acl.localhost / doc?docid=http: // sharepoint.domain.com: / UserLibrary / Forms /AllItems.aspx|2

  1. Permitted Users
  1. Permitted Groups
  1. kerbadmin
  2. local service
  3. network service
  1. DOMAIN\user_group
  2. [http://sharepoint.domain.com:14357][GSSiteCollectionAdministrator]
  3. [http://sharepoint.domain.com:14357]testsite Members
  4. [http://sharepoint.domain.com:14357]testsite Owners
  5. [http://sharepoint.domain.com:14357]testsite Visitors

 

 

Note that we now have a permitted group of "DOMAIN\user_group".

If we attempt a secure search on the GSA as a user(gsa1) who is a member of this AD group the following will be observed in the authorization log.

[GSA_ADMIN_LOG]  session id: 15ece6c3a1de0c328c9610e4c4697382 verifiedUserId: gsa1 groups: [DOMAIN\remote desktop users, DOMAIN\user_group]
120510 17:27:54.779:I 10254 [com.google.enterprise.authzchecker.PolicyProcessor.processTransparentAcl] Policy verification for url: googleconnector://kerb_sp_acl.localhost/doc?docid=http://sharepoint.domain.com:14357/Shared%20Documents/Forms/AllItems.aspx%7C2
...
120510 17:27:54.779:I 10254 [com.google.enterprise.authzchecker.AuthzRequestProcessor.logResults] [[GSA_ADMIN_LOG] Authorization results for session: 15ece6c3a1de0c328c9610e4c4697382 decision [1/2] PERMIT by POLICY for URL googleconnector://kerb_sp_acl.localhost/doc?docid=http://sharepoint.domain.com:14357/Shared%20Documents/Forms/AllItems.aspx%7C2

 

 

Permit by Policy has been returned for the document set to read access, removing this permission or removing the group from SharePoint and refeeding will result in a Deny by Policy

 

Troubleshooting

 

Cannot connect to the given SharePoint Site URL with the supplied Domain/Username/Password.Reason:(401)Unauthorized

 

If you are encountering a 401 Unauthorized during configuration of the Connector for SharePoint,

  • Ensure you are logging in as user with administration (full access) rights to the SharePoint server.
  • If filling in the domain field, ensure you have the domain listed in lower case and the same string as is defined in Windows. eg, domain. Not DOMAIN or domain.com .
  • If you are using authorization by connector, please ensure you have google services for SharePoint installed on the SharePoint server.

 

AuthZ log shows Indeterminate or Deny for documents

AuthZ log shows messages as follows.
[GSA_ADMIN_LOG] Authorization results for session: 9d2d3ef166fe14f1ae67ecd3fb47d81b decision [12/16] DENY by POLICY for URL googleconnector://kerb_sp_acl.localhost/doc?docid=http://sharepoint.domain.com:14357/Lists/Tasks/AllItems.aspx%7C%7BD1152B3C-9DDD-4C4B-8B83-8A167B125905%7D
or
[GSA_ADMIN_LOG] Authorization results for session: 9d2d3ef166fe14f1ae67ecd3fb47d81b decision [12/16] INDETERMINATE by CONNECTOR for URL googleconnector://kerb_sp_acl.localhost/doc?docid=http://sharepoint.domain.com:14357/Lists/Tasks/AllItems.aspx%7C%7BD1152B3C-9DDD-4C4B-8B83-8A167B125905%7D
Deny by policy simply means as it suggests, the ACL for the URL does not match the users. If you suspect this to be incorrect, check the ACL details for that document in crawl diagnostics and then ensure that the same ACL string is being returned for that user in the connector log. Indeterminiate should also be for a similar reason, eg. an explicit ACL has not been created for the user, if there is misconfiguration on the user side, this error may be observerd. Once again review the users setup and ensure that the group and user ACL's returned match the ones in crawl diagnostics for this URL. It's possible for example that the user has been locked out in Active Directory.

 

 

ACLs appear to be ok but intermittently return Deny for certain documents

 

If your content server makes use of 302 redirects, it's possible that the source page and destination page may be different. This is especially prevalent in sites that make heavy use of javascript. You may be hitting such an issue if.. - a source page does a 302 redirect to a destination page - source page has no ACL - destination page has ACL - a generic keyword is used to query as a search query which will match both source and destination URL's To work around this, ensure to feed the same ACL for both source and destination. The reason for this issue is to ensure malicious redirects could not be used to bypass ACL's

Security Manager log shows : Failed to get identity from Kerberos

 

Security Manager Log shows the following message.

120315 10:37:21.160:X 38 [com.google.net.rpc3.impl.client.RpcNetChannel.completeRpcRequest] Channel 1: RPC b298c07d1ab6639d failed on localhost:11913 : /SessionManagerProto.StoreKrb5Identity to 127.0.0.1:11913 [SERVER_ERROR] server generated an incomplete reply: identity
120315 10:37:21.162:X 31 [com.google.enterprise.sessionmanager.SessionManagerClient.handleRpcException] RPC warning SERVER_ERROR: server generated an incomplete reply: identity
120315 10:37:21.162:I 31 [.modules.KerberosCredentialsGatherer.validateResponse] sid 9d2d3ef166fe14f1ae67ecd3fb47d81b: Failed to get identity from Kerberos.
120315 10:37:21.162:I 31 [.authncontroller.AuthnSession.updateSessionState] sid 9d2d3ef166fe14f1ae67ecd3fb47d81b: Modify session state:
  add to http://google.com/enterprise/gsa/security-manager/kerberos: {Verification: status=REFUTED; expires after request}
The above error at serve time indicates that the GSA failed to complete the kerberos transaction. This could be due to having a mis configured kerberized environment, it will also be seen when attempting to search from outside of your kerberized domain. Ensure you have kerberos configured correctly as described in the official documentation.

 

The Web application could not be found

Connector Log shows the following message.
The Web application at
http://sharepoint.domain.com:14357/Shared%20Documents/Forms/AllItems.aspx could not be found. Verify that you have typed the URL correctly.
If the URLshould be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.
This is caused by a non FQDN entry as an Alternate Access Mapping in SharePoint Central Administration. To work around this issue follow the below steps.
  • Open SharePoint Central Administration from SharePoint server.
  • Navigate to the Operation Tab.
  • Under Global Configuration section, click the "Alternate Access Mappings" link.
  • Click on the Web application link for which you want to change the access mapping.
  • Edit the URL and change it to FQDN format i.e. Fully qualified Domain Name.
  •  

 

Was this helpful?
How can we improve it?