I needed to connect to MYSQL databases via asp.net. I am using MySQL Connector to make connection with database but while doing this I am having this Error:
Authentication with old password no longer supported, use 4.1 style passwords.
From MySQL 4.1 and higher they use a new protocol that is not compatible with earlier versions. Which is why when you upgrade the server from an earlier version to 4.1 or higher you receive the authentication error message.
If you need to connect to the database with both clients before and after version 4.1 you must have two passwords stored. One the old way and one the new way.
You can set a users password to the new way using:
SET PASSWORD for <username> = PASSWORD('new password')
SET PASSWORD FOR 'steve'#'10.15.2.67' = PASSWORD('my secure password');
If needed you can also set passwords to the old way using:
SET PASSWORD for <username> = OLD_PASSWORD('new password')
SET PASSWORD FOR 'steve'#'10.15.2.67' = OLD_PASSWORD('my secure password');
There is a great page in the MySQL manual which will detail the process
You can actually for the server if newer than 4.1 to still use the old password method however this isn't recommended.
To do this, you can start the server with the --old-passwords option.
So, either the server has updated and you're using a old client - or you've updated your client (which now uses the new password system) and your connecting to a server below 4.1
ok but if you do not have the authorization to do this,simply because you are in a shared hosting environment:
SET PASSWORD for <username> = OLD_PASSWORD('new password')
SET PASSWORD FOR 'steve'#'10.15.2.67' = OLD_PASSWORD('my secure password');
What can you do?
I have not found a workaround and my hosting provider has changed the mysql configuration without warning...nor giving solutions.
UNCOMPLETE SOLUTION
You can force the web.config to use the old connector. It seems to work, but mysql errors occur... so I think there is a bug somewhere in the connectors.
Related
I've encountered a challenge regarding internet-facing deployment installation for CRM using a AD FS server. After the setup is complete, users are able to access the CRM server - but when trying to run custom pages the following error message is prompted:
"The authentication endpoint Kerberos was not found on the configured Secure Token Service!"
I've found several solutions on the internet for this issue:
First I found a KB article from Microsoft providing a possible
solution, this involves updating MEX endpoints by running a provided
PowerShell script.
(https://support.microsoft.com/en-us/help/2828015/configuring-ad-fs-2.1-with-microsoft-dynamics-crm-2011).
But this doesn't seem to be the issue.
Another solution could be to update the CRM rollup version (currently have version 14 installed, latest is version 18) - this is something that I want to avoid as it might lead to further issues.
Have anybody else encountered a similar issue, and in that case how did you solve it?
I have just spent last few days to figure this exact same error message and it turned out that it was the "Domain" attribute in crm connection string. Copied my answer to my own question at the Microsoft Dynamics CRM community forum here:
"Well, I found the culprit - it was the Domain attribute in the connection string:
For connecting from outside the domain, it does not like to have a Domain in the connection string:
Connection string format 1 (without Domain attribute): "Authentication Type=Passport;Server=https://devcrm.myco.com;Username=devuser#myco.com;Password=pwd" - this works both inside and outside the domain "myco.com"
Connection string format 2 (with Domain attribute): "Authentication Type=Passport;Server=https://devcrm.myco.com;Domain=myco;Username=devuser#myco.com;Password=pwd" - this only works inside the domain myco.com but NOT outside (exception: The authentication endpoint Kerberos was not found on the configured Secure Token Service!)
The key is in the Xrm.Client.CrmConnection.ClientCredential:
If Domain is NOT specified in the connection string, when connecting from outside domain, Xrm.Client.CrmConnection.ClientCredentials.UserName is populated whereas the ClientCredentials.Windows.ClientCredentials.UserName is empty.
But if the Domain is specified, Xrm.Client.CrmConnection.ClientCredentials.UserName becomes null and Xrm.Client.CrmConnection.ClientCredentials.Windows.ClientCredentials.UserName populated, which led to the service trying to authenticate user as a Windows AD user so of course it would fail when running app from outside Windows domain. And it explains why the same app works inside the domain even with Domain specified in the connection string.
For more detail, refer here for my original post asking for help in Dynamics CRM Forum
I am trying to configure alfresco 5.0d community to use kerberos and SSO via active directory.
My setup works fine when I login in the alfresco form login page (without SSO),
However, When enabling SSO, I see this exception in the alfresco logfile:
KrbException: KDC cannot accommodate requested option (13)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:70)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:259)
After looking at it with wireshark, it seems like the difference in the TGS-REQ message is that when using SSO, there is an option flag called request-anonymous that is enabled. This causes the KDC to answer with a KDC_ERR_BADOPTION message.
Is there a way to configure kerberos to not set the request-anonymous flag?
Or alternitavely, is there a way to tell the KDC server to deal with it properly?
OpenAM version -12 , Agent version 3.5 and 3.3 , tomcat version 7
I have tried to follow the link https://forums.alfresco.com/forum/installation-upgrades-configuration-integration/authentication-ldap-sso/sso-openam-06052012 to set up my J2EE Agent. Let me paste the steps after asking the question(see at the end)
but I am getting the error as asked below
Not able to configure J2ee agent on adding my customized data store for users
I have tried to use 3.5 version installed and uninstalled multiple times and tried previous version.
There is a nice discussion on this topic at http://database.developer-works.com/article/16009911/%22Cannot+obtain+Application+SSO+token%22+error
but it did not help me much.
I am using LDAP so I have used LDAP realm and subjects are showing up ok. Also I am observing that the policy tab has changed quite a bit from how it is described in the Blogs.
Now with the roadblock I am not sure how to proceed as the error is not giving me any clue what to do. I even added the file named AMConfig.properties in the classpath with username and password of the agent and tried the username and password of the OpenAM admin too as suggested in the discussion mentioned. but that too did not help.
The issue is the Tomcat now is not starting and giving error that AMConfig.properties properties are needed
I know the OpenAM Realm setup is good as I am able to login via this realm to another application (Liferay) where I just have to give the URL for use OpenAM integration. but after uninstallation of the agent the tomcat starts without any error and i am able to login to the application
-------------------Step copied from 1st link(modified)--------------------------
1. Configure your OpenAM agent (tried both 3.5 and 3.3 version on tomcat 7)
a. Log into OpenAM as the admin user and navigate to "Access Control -> (Your Realm) - where in my case LDAP Realm (other application using it without issue)
b. Select Policies -> New Policy
c. Enter Share as the policy name and then create 2 new URL Policy agent rules
d. 1st Resource Name = http://:/share/*
e. 2nd Resource Name = http://alfresco.domain.com:8080/share/*?*
f. Add a subjects - already part of LDAP Realm
g. Now select Agents -> J2EE - > (your J2EE agent)
h. Select the Application tab
i. Login Processing -> Login Form URI - add /share/page/dologin
j. Logout Processing -> Application Logout URL - add Map Key = share - Corresponding Map Value = /share/page/dologout
k. Not Enforced URI Processing - Add 2 entries - /share and /share/
l. Profile Attributes Processing - Select HTTP_HEADER and add Map Key = uid - Corresponding Map Value = SsoUserHeader (This is what I called my header in the alfresco-global.properties file - see below)
Auth chain
authentication.chain=external1:external,alfrescoNtlm1:alfrescoNtlm
alfresco.authentication.allowGuestLogin=true
SSO settings
external.authentication.enabled=true
external.authentication.defaultAdministratorUserNames=admin
external.authentication.proxyUserName=
external.authentication.proxyHeader=SsoUserHeader
NOTE- It does not seem possible to configure SSO where the Guest login has been disabled. There are webscripts used on the Alfresco repository that need guest login.
That concludes the setup for Alfresco and OpenAM
For Share you need to have the following section uncommented in your share-config-custom.xml
alfresco/web-extension/alfresco-system.p12
pkcs12
alfresco-system
alfrescoCookie
Alfresco Connector
Connects to an Alfresco instance using cookie-based authentication
org.alfresco.web.site.servlet.SlingshotAlfrescoConnector
alfrescoHeader
Alfresco Connector
Connects to an Alfresco instance using header and cookie-based authentication
org.alfresco.web.site.servlet.SlingshotAlfrescoConnector
SsoUserHeader
alfresco
Alfresco - user access
Access to Alfresco Repository WebScripts that require user authentication
alfrescoHeader
http://alfreso.domain.com:8080/alfresco/wcs
user
true
Notice I am not using the SSL cert and in my alfrescoHeader connector I have used SsoUserHeader (as setup in OpenAM) and the endpoint uses the alfrescoHeader connector
Now you need to add the OpenAM filter to the Share web.xml file
Add the following filter just before the Share SSO authentication support filter
Agent
com.sun.identity.agents.filter.AmAgentFilter
Add the following filter mapping to the filter-mapping section
Agent
REQUEST
INCLUDE
FORWARD
ERROR
----- End ----------
The error message is a bit misleading: the Cannot obtain application SSO token in general means that the agent was unable to authenticate itself. When you install the agent, the agent asks for a profile name and a password file, those values need to correspond to the agent profile configured within OpenAM.
To test if you can authenticate as the user, you could simply try to authenticate as the agent by making the following request:
curl -d "username=profilename&password=password&uri=realm=/%26module=Application" http://aldaris.sch.bme.hu:8080/openam/identity/authenticate
In the above command the realm value needs to be the same as the value for the "com.sun.identity.agents.config.organization.name" property defined in OpenSSOAgentBootstrap.properties (under the agent's install directory).
Having bad username/password combination is only one of the possible root causes for this exception though. It is also possible that during startup the agent was unable to connect to OpenAM to authenticate itself. In those cases the problem could be:
network error, firewall issues preventing the agent from contacting OpenAM
SSL trust issues: agent's JVM does not trust the certificate of OpenAM's container (only problem if you've installed the agent by providing OpenAM's HTTPS URL and the certificate is self-signed or just simply not trusted by the JVM)
I am using drupal 7.27 version in which I need to connect to moodle site and its database. So I used drupal module moodle_connection to connect it withmoodle site. As it does not offer any end feature functionality. I installed another module called moodle_views but unfortunately there is no data received from the moodle. When I debug I found that connection does not establish between both the sites.
I am calling moodle_connector_connect() function in custom module to connect to Moodle. But no success. And in the moodle connector settings I put the following information:
Database Type : mysql
Database Server : localhost
Database TCP Port : 3306
Database Name : drupal_moodle ('Name of the moodle database')
Database Prefix : mdl_
Database User : root
Database Password : (I don't have password for my database user so I kept blank)
Moodle URL : drupal_moodle (Moodle site url)
Please help me to get out of this.
Regards
Neha
Reading over the bug reports in the Drupal module moodle_connector, I noticed some issues related to setting values for the moodle database connection variables, and some issues with handling error conditions.
Combine this with your mention of blank password, suggests the following line might be a problem.
Reading moodle_connector.module, around line 51 I notice some lazy checking for unset parameters.
// Return false if settings are incomplete.
if (!$type || !$server || !$port || !$username || !$password || !$database) {
return FALSE;
}
It looks like the check for !$password will cause the function moodle_connector_connect() to exit and not connect to the moodle database if any of the values are unset or empty.
As a workaround, and a step in right direction security-wise, could you create a new MySQL user, specifically grant it the necessary privileges to allow Drupal to read the Moodle DB and set a password.
I would also strongly advise that you read over the MySQL 'post installation' section of the manual which advises setting a password on the root user accounts. Having no root password is convenient during initial installation, but is a security problem. Any ordinary user on the machine, or a nearby machine which can connect to port 3306, could gain full access to the database.
http://dev.mysql.com/doc/refman/5.1/en/postinstallation.html
I'm tried to pull some SharePoint 2013 list data I created which works fine when running locally on my machine and when run locally one the server. I'm user the same credentials when running both locally and locally on the server. The issue is when I publish and navigate to my ASP.NET app on the server I get the "The remote server returned an error: (401) Unauthorized." Error...
I've looked at a bunch of the posts on stackoverflow and some other articles on the web
This points out that the context seems to be using IUSR:
http://blogs.msdn.com/b/sridhara/archive/2014/02/06/sharepoint-2013-csom-call-from-web-part-fails-with-401-for-all-users.aspx
This one mentions to try setting the default network credentials:
https://sharepoint.stackexchange.com/questions/10364/http-401-unauthorized-using-the-managed-client-object-model
I've tried using the fixes mentioned in the article as well as trying to force the context to use DefaultNetworkCredentials but no luck. I would like for the app to use the credentials of the logged in user and not the machine...
Here is the code I'm using:
SP.ClientContext context = new SP.ClientContext("MySPDevInstance");
context.Credentials = CredentialCache.DefaultNetworkCredentials;
Entity entity = context.Web.GetEntity(collectionNamespace, collectionName);
LobSystem lobSystem = entity.GetLobSystem();
LobSystemInstanceCollection lobSystemInstanceCollection = lobSystem.GetLobSystemInstances();
context.Load(lobSystemInstanceCollection);
context.ExecuteQuery();
LobSystemInstance lobSystemInstance = lobSystemInstanceCollection[0];
FilterCollection filterCollection = entity.GetFilters(filter);
filterCollection.SetFilterValue("LimitFilter", 0, 1000);
EntityInstanceCollection items = entity.FindFiltered(filterCollection, filter, lobSystemInstance);
The server is running IIS 6.0
Any advice would be much appreciated!
Thank you
I presume your ASP.NET web site is using Windows Integrated (NTLM) authentication. A user authenticated this way cannot authenticate to a second location from the server side (the web server.) You are experiencing what is known as the "double-hop" (1) limitation of NTLM. You must use a dedicated account on the server side, or if you really do want to use the logged-in user's identity, you must use an authentication scheme that permits delegation, such as Kerberos.
If you really need the user's identity to access SharePoint data and you cannot change the authentication scheme, then the best way to do this is to use the JavaScript CSOM. This means the user is authenticating directly to the SharePoint server (a single hop, not double) and your ASP.NET site serves the page containing this script to the user.
(1) http://blogs.msdn.com/b/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
Use Default Credentials worked for me:
HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(url);
httpWebRequest.UseDefaultCredentials = true;
Setup the crendentials by code:
SP.ClientContext context = new SP.ClientContext("MySPDevInstance");
context.Credentials = new NetworkCredential("username", "password");
You should put this at the configuration file to change it without publishing or recompiling the application.
Just to add one more setting that I encountered. If the account is restricted to access only certain servers than add the client machine to that account as well. For example if a web application is hosted on Server A and trying to connect to SharePoint 2010 on Server B with account ABC then make sure that account has access to Server A in Active Directory. Normally the AD account doesn't have restrictions to connect to machines but in my case the account was restricted to only certain machines. I added my web application hosted server to the account and it worked.