I have a web application using SPServices to communicate with a SP 2010 site that has been upgraded to SP 2013. Both my application server and the SP server reside in the same domain, let's call it domain1.
Until now, the SP 2010 worked with basic Windows authentication and everything worked OK with the SPServices from my website. I did not specify any authentication in the SPServices, current Windows user credentials were used for the connection with the SP site. Let's call the windows login user: domain1\myUser
Now, the SP 2013 site uses Claims based authentication and I can see that there are 2 users in SP now, one is the old domain1\myUser and the other is the claims user i:0#.w|domain1\myUser.
Is it possible to still have the user connect to windows using the same login domain1\myUser but have SPServices authenticate the user as i:0#.w|domain1\myUser instead of the old one?
I can provide more details/clarifications if needed.
To be more specific, my actual problem is the following:
In my SP 2013 I have 2 user profiles for the same user, the windows user profile and the claims user profile, which have different SP ids.
SP services functions are using the windows logged in user profile like domain1\myUser. However, when for example I checkout a document item, the item's checkout user id attribute is equal to the equivalent claim's user id and not the windows user id.
In order to check whether an item is checked out to current user (to allow editing, checkin, etc) I used to check the current SP services user id with the item's checkout user id. And based on the above, after installing the claims based authentication, this check fails now.