I am unable to use cookieless sessions in SharePoint. Everytime when I click on a site or subsite a new session id is getting created which is not as per expected behaviour (it is visible in the URL). How can I use cookieless sessions in SharePoint?
Create a Shared Services Provider. This is required in order to enable Session State and its content database is the location of our session data. If you already have an SSP, you can use the existing one.
If needed, associate your web application with this SSP (done by default if it is your first SSP).
In Central Administration, under Application Management, choose Session State, and ensure that it is enabled.
From a command prompt, navigate to the Microsoft.NET 2.0 Framework directory
(typically: C:WINDOWSMicrosoft.NETFrameworkv2.0.50727)
Modify your web.config:
Uncomment the following line:
<add name=”Session” type=”System.Web.SessionState.SessionStateModule” />
Modify the following line:
<pages enableSessionState=”true” … />
Run the following command:
aspnet_regsql.exe -S -d -ssadd -sstype c -E
where:
<server_name> is the database server where your database is located
<database_name> is the content database of your shared services provider
Run aspnet_regsql.exe /? for more information on the remaining options
Related
We are currently testing azure web-app functionality for our own apache application. The application works with non security, but the application itself needs direct active directory access via ldap.
Example settings inside the application:
<ldap>
<connectionUrl>wehavenoidea:389</connectionUrl>
<roleBase>OU=AADDC Users,DC=ourdomain,DC=onmicrosoft,DC=com</roleBase>
<userPattern>{0},OU=AADDC Users,DC=ourdomain,DC=onmicrosoft,DC=com</userPattern>
<roleSearch>member={0}</roleSearch>
<useIndirectLookup>1</useIndirectLookup>
<indirectAdminDN>CN=AdminUser,OU=AADDC Users,DC=ourdomain,DC=onmicrosoft,DC=com</indirectAdminDN>
<indirectAdminPassword>ourpassword</indirectAdminPassword>
<indirectUserBase>DC=ourdomain,DC=onmicrosoft,DC=com</indirectUserBase>
<indirectSearchFilter>sAMAccountName={0}</indirectSearchFilter>
<rolemap>
<role target="Admin">Admin</role>
<role target="Accounting">Accounting</role>
</rolemap>
</ldap>
I have set up the app registration inside azure active directory with the required permissions. I can't find the connection url for the AD though.
Does anybody here know how to set this up?
Kind regards
We have web application deploy on Azure App Service. Our database is also on Azure which is configured to use AAD authentication (We have assigned AAD Admin).
We are using below connection string in web app to connect to this server and database using below connections string.
Data Source=xxxxxxx.database.windows.net;Initial
Catalog=xxxxxxx;Persist Security Info=False;Authentication=Active
Directory Integrated
Please note: This connection string is working fine when using thru local system. But getting below error when we use this conn string in Azure App Service:
Failed to authenticate the user NT Authority\Anonymous Logon in Active
Directory (Authentication=ActiveDirectoryIntegrated). Error code
0x4BC; state 10 The format of the specified domain name is invalid
According to your description, I found you used the Active Directory integrated authentication.
To use integrated Windows authentication, your domain’s Active Directory must be federated with Azure Active Directory. Your client application (or a service) connecting to the database must be running on a domain-joined machine under a user’s domain credentials
If you published the web app to Azure, Azure's web app server will not be in your domain’s Active Directory. So the SQL server will not pass the auth.
I suggest you could try to use Active Directory password authentication instead of the Active Directory integrated authentication.
Replace the connection string as below use azure AD user name and password. It will work well.
Server=tcp:brandotest.database.windows.net,1433;Initial Catalog=bradnotestsql;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Authentication="Active Directory Password";
Since the accepted answers are a bit dated, if you are out here in 2020 or later, the correct way for setting up integrated authentication is as follows:
(excerpted from here, the asp.net standard implementation)
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi
add the Microsoft.Azure.Services.AppAuthentication nuget package.
modify your web.config by adding: (in configSections)
<section name="SqlAuthenticationProviders" type="System.Data.SqlClient.SqlAuthenticationProviderConfigurationSection, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
(and then)
<SqlAuthenticationProviders>
<providers>
<add name="Active Directory Interactive" type="Microsoft.Azure.Services.AppAuthentication.SqlAppAuthenticationProvider, Microsoft.Azure.Services.AppAuthentication" />
</providers>
</SqlAuthenticationProviders>
It's important to pay attention to the name you use there. Then... your connection string will look like:
<add name="MyEntities" connectionString="metadata=res://*/Data.MyDB.csdl|res://*/Data.MyDB.ssdl|res://*/Data.MyDB.msl;provider=System.Data.SqlClient;provider connection string="server=tcp:MyDB.database.windows.net;database=MyDB;UID=AnyString;Authentication=Active Directory Interactive;"" providerName="System.Data.EntityClient" />
The important notes are that the name you specify in the SqlAuthenticationProviders section must be the exact same name you use in the connection string for Authentication.
The other important note is that, coming from your old connection strings, you have to change Data Source to be Server, and Initial Catalog to be Database. UID=AnyString is necessary, or an exception is thrown.
Failure to follow these steps exactly will net you a lovely error:
System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> AdalException: The format of the specified domain name is invalid.\r\n at ADALNativeWrapper.ADALGetAccessToken(String username, IntPtr password, String stsURL, String servicePrincipalName, ValueType correlationId, String clientId, Boolean* fWindowsIntegrated, Int64& fileTime)\r\n at System.Data.SqlClient.ActiveDirectoryNativeAuthenticationProvider.<>c__DisplayClass2_0.b__0()\r\n at System.Threading.Tasks.Task`1.InnerInvoke()\r\n at System.Threading.Tasks.Task.Execute()\r\n --- End of inner exception stack trace
At the first the error doesn't make sense, but once you see that the parameters were renamed from Data Source to Server, it does make sense.
Maybe all you need to use is token (certificate) authentication as explained on below resource:
https://github.com/Microsoft/sql-server-samples/tree/master/samples/features/security/azure-active-directory-auth/token
Try to register your application with Azure Active Directory as explained on that resource.
Hope this helps.
Because the old connect to CRM Online is deprecated, we have to use the new method for CRM 2017 Online.
The following procedure runs well at the local development system, but not at the target area, which is a Azure Web App:
CrmConnectionString = "AuthType=Office365; Url=https://<Org>.api.crm4.dynamics.com; Username=<User>; Password=<PW>;"
CrmServiceClient conn = new CrmServiceClient(CrmConnectionString);
Also tried:
CrmServiceClient conn =
new CrmServiceClient(
"<User>",
CrmServiceClient.MakeSecureString("<PW>"),
string.Empty,
"<Org>",
useUniqueInstance: false, useSsl: true, isOffice365: true);
Based on https://community.dynamics.com/crm/f/117/t/188785 also added to web.config:
<system.net>
<defaultProxy useDefaultCredentials="true"/>
</system.net>
Also try from https://blog.vertica.dk/2016/03/04/crm-2016-unable-to-login-to-dynamics-crm/:
WEBSITE_LOAD_USER_PROFILE=1 at appsettings
Nothing happens.
The authentication data and addresses are correct. It's only failed in the Azure enviroment.
Any solutions?
According to Kudu Configurable settings, WEBSITE_LOAD_USER_PROFILE is only available for sites running in Basic or Standard mode. Please check which Web App Plan pricing plan did you choose?
You can also check whether the WEBSITE_LOAD_USER_PROFILE has been applied successfully using Azure Kudu site. On CMD page, redirect to Users folder using 'CD D:\Users' command, you will see a user which has a same name as your web app. If the specific user doesn't not exists, it means the USER_PROFILE has not been loaded.
CD D:\Users
Service Fabric RunAs feature
By default, a Service Fabric application will run with the Network Service account. Microsoft has (partial) documentation on how to run it with other permissions: RunAs: Run a Service Fabric application with different security permissions.
Based on this, here's what I'm trying to do:
My Service Fabric application calls a library that is being developed in an other repository.
When deployed in the cloud, the services will download the binaries for the library from a storage, unzip them in a working directory of the Service Fabric cluster and load it from there.
At development time, when I'm testing or debugging the application in a local cluster, I want the binaries for the library to be loaded from some folder on my local hard drive where I have just compiled them, that is right next to the source code.
The tricky part is that my company's security policies require the source code of said library to be accessible only to authorized users, which translates into the folder containing this code being read-protected. As a consequence my Service Fabric application, which runs as Network Service, can't access my binaries. Changing the security policies is not possible, nor giving Network Service access to the folder.
How can I configure my application so that it runs as a user that would have the correct access rights ?
Here's what I already tried:
Using a domain user
The easiest solution would be to be able to run the Service Fabric application with my own login. I tried this by adding the following to my ApplicationManifest.xml:
<Principals>
<Users>
<User Name="SfUser" AccountName="Domain\UserName" AccountType="DomainUser" Password="pass" />
</Users>
</Principals>
<Policies>
<DefaultRunAsPolicy UserRef="SfUser" />
</Policies>
This works: the application runs as Domain\UserName and can access all the folders I need. But this requires me to put my password in the configuration file, which is not satisfactory.
Using a local user
I then tried using a local user, thinking I would be able to configure access rights correctly using local user groups. The simplest version I could come up with is this:
<Principals>
<Users>
<User Name="SfUser" AccountName="LocalSfUser" AccountType="LocalUser">
<MemberOf>
<SystemGroup Name="MyLocalGroup"/>
</MemberOf>
</User>
</Users>
</Principals>
<Policies>
<DefaultRunAsPolicy UserRef="SfUser" />
</Policies>
I think this configuration is correct since when I deploy my application I can see in Windows user manager that several "technical" users where created by Service Fabric and that they belong to MyLocalGroup. However my application never starts.
I noticed several messages in Windows event viewer that seem related to the problem:
Logon Type: 8
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Process Information:
Caller Process Name: C:\Program Files\Microsoft Service Fabric\bin\FabricHost.exe
Apparently, "Logon Type 8" means "Network clear text logon". I suspect a local policy preventing this kind of logon in my company.
When you run as a localuser, this creates a random local user account on the machine. The reason this is most likely failing in the example above is the <SystemGroup Name="MyLocalGroup"/> needs to be a valid Windows system group such as "Administrators". You also do not really need the AccountName attribute above, but it does no harm.
To solve you issue of getting a file from a remote directory you need to use a domain user as you tried since a local user does not have a shared secret that can be verified with AD. The difference is that you can encrypt the password in the application manifest using a certificate that is deployed to the machine. I have put an example ApplicationManifest.xml snippet below, showing how the password for the domain user is encrypted with a certificate called "MyCert".
<Principals>
<Users>
<User Name="TestUser" AccountType="DomainUser" AccountName="Domain\User" Password="[Put Encrypted Password Here" PasswordEncrypted="true" />
</Users>
</Principals>
<Policies>
<DefaultRunAsPolicy UserRef="TestUser" />
<SecurityAccessPolicies>
<SecurityAccessPolicy ResourceRef="MyCert" PrincipalRef="TestUser" GrantRights="Full" ResourceType="Certificate" />
</SecurityAccessPolicies>
</Policies>
As a side note the article here https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-secret-management show how to create the encrypted password in settings.xml which is also often useful.
I have an ASP.NET Web API service that runs on a web server with Windows Authentication enabled.
I have a client site built on MVC4 that runs in a different site on the same web server that uses the HttpClient to pull data from the service. This client site runs with identity impersonation enabled and also uses windows authentication.
The web server is Windows Server 2008 R2 with IIS 7.5.
The challenge I am having is getting the HttpClient to pass the current windows user as part of its authentication process. I have configured the HttpClient in this manner:
var clientHandler = new HttpClientHandler();
clientHandler.UseDefaultCredentials = true;
clientHandler.PreAuthenticate = true;
clientHandler.ClientCertificateOptions = ClientCertificateOption.Automatic;
var httpClient = new HttpClient(clientHandler);
My understanding is that running the site with identity impersonation enabled and then building the client in this manner should result in the client authenticating to the service using the impersonated identity of the currently logged in user.
This is not happening. In fact, the client doesn't seem to be authenticating at all.
The service is configured to use windows authentication and this seems to work perfectly. I can go to http://server/api/shippers in my web browser and be prompted for windows authentication, once entered I receive the data requested.
In the IIS logs I see the API requests being received with no authentication and receiving a 401 challenge response.
Documentation on this one seems to be sparse.
I need some insight into what could be wrong or another way to use windows authentication with this application.
Thank You,
Craig
I have investigated the source code of HttpClientHandler (the latest version I was able to get my hands on) and this is what can be found in SendAsync method:
// BeginGetResponse/BeginGetRequestStream have a lot of setup work to do before becoming async
// (proxy, dns, connection pooling, etc). Run these on a separate thread.
// Do not provide a cancellation token; if this helper task could be canceled before starting then
// nobody would complete the tcs.
Task.Factory.StartNew(startRequest, state);
Now if you check within your code the value of SecurityContext.IsWindowsIdentityFlowSuppressed() you will most probably get true. In result the StartRequest method is executed in new thread with the credentials of the asp.net process (not the credentials of the impersonated user).
There are two possible ways out of this. If you have access to yours server aspnet_config.config, you should set following settings (setting those in web.config seems to have no effect):
<legacyImpersonationPolicy enabled="false"/>
<alwaysFlowImpersonationPolicy enabled="true"/>
If you can't change the aspnet_config.config you will have to create your own HttpClientHandler to support this scenario.
UPDATE REGARDING THE USAGE OF FQDN
The issue you have hit here is a feature in Windows that is designed to protect against "reflection attacks". To work around this you need to whitelist the domain you are trying to access on the machine that is trying to access the server. Follow below steps:
Go to Start --> Run --> regedit
Locate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 registry key.
Right-click on it, choose New and then Multi-String Value.
Type BackConnectionHostNames (ENTER).
Right-click just created value and choose Modify.
Put the host name(s) for the site(s) that are on the local computer in the value box and click OK (each host name/FQDN needs to be on it's own line, no wildcards, the name must be exact match).
Save everything and restart the machine
You can read full KB article regarding the issue here.
I was also having this same problem. Thanks to the research done by #tpeczek, I developed the following solution: instead of using the HttpClient (which creates threads and sends requests async,) I used the WebClient class which issues requests on the same thread. Doing so enables me to pass on the user's identity to WebAPI from another ASP.NET application.
The obvious downside is that this will not work async.
var wi = (WindowsIdentity)HttpContext.User.Identity;
var wic = wi.Impersonate();
try
{
var data = JsonConvert.SerializeObject(new
{
Property1 = 1,
Property2 = "blah"
});
using (var client = new WebClient { UseDefaultCredentials = true })
{
client.Headers.Add(HttpRequestHeader.ContentType, "application/json; charset=utf-8");
client.UploadData("http://url/api/controller", "POST", Encoding.UTF8.GetBytes(data));
}
}
catch (Exception exc)
{
// handle exception
}
finally
{
wic.Undo();
}
Note: Requires NuGet package: Newtonsoft.Json, which is the same JSON serializer WebAPI uses.
The reason why this is not working is because you need double hop authentication.
The first hop is the web server, getting impersonation with Windows authentication to work there is no problem. But when using HttpClient or WebClient to authenticate you to another server, the web server needs to run on an account that has permission to do the necessary delegation.
See the following for more details:
http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx
Fix using the "setspn" command:
http://www.phishthis.com/2009/10/24/how-to-configure-ad-sql-and-iis-for-two-hop-kerberos-authentication-2/
(You will need sufficient access rights to perform these operations.)
Just consider what would happen if any server was allowed to forward your credentials as it pleases... To avoid this security issue, the domain controller needs to know which accounts are allowed to perform the delegation.
To impersonate the original (authenticated) user, use the following configuration in the Web.config file:
<authentication mode="Windows" />
<identity impersonate="true" />
With this configuration, ASP.NET always impersonates the authenticated user, and all resource access is performed using the authenticated user's security context.