We Keep Coding

DocuSign C# API - USER_LACKS_MEMBERSHIP error for every token-authenticated request

We had a working application, we went through the go-live process, and everything was running live for several days. Then we started getting SSL errors, and we saw that the nuget package for the DocuSign package had an update (I believe this was all for the 11/13/2019 2019 certificates auto-update), so we updated our code, but now every request returns the USER_LACKS_MEMBERSHIP error for every token-authenticated request.
Things I can confirm are not the issue:
We have authenticated the app via account.docusign.com and the oauth signature impersonation scope, and the testing and live paths are in the API approved Redirect URIs.
We have the correct base path in the configuration (https://na3.docusign.net, as shown on our Apps and Keys page)
The base path did not change after we get the token back (The BaseUri on the Account object matches what we started with)
We are using the correct user for the configuration (The value labeled "API Username" in the Apps and Keys page is entered as "IMPERSONATED_USER_GUID" in appsettings.json and successfully used in creating the token as parameter UserID, which also matches our user account's ID shown in the backend, so we are not confusing it with TARGET_ACCOUNT_ID or CLIENT_ID, and shuffling those around causes errors much earlier at the token generation step).
We only have one user: the administrator of the DocuSign account. Their ID appears in the API configuration labeled as "API Username". The DocuSign administration backend doesn't display a membership tab anywhere for us to correct any possible issues with a user lacking membership. As far as I can tell, Membership is a higher tier account option than what we're paying for, so I'm confused how we could be having problems with a feature we haven't bought.
We get this error for checking envelope status. We get this error for trying to create new envelopes. We get this error for trying to get Account information. The only thing we can do is get an authentication token, but then that token can't be used to make any further authenticated requests.
Is there anything I'm missing that could be causing this other than some database error on DocuSign that I can't correct through the tools available to me? The package update changed the order of which class constructor accepts the ApiClient object, and there's a new AccessToken field on the Configuration class (which I filled out, but doesn't seem to have any effect, since we're still adding the Authorization/Bearer header manually). I'm out of ideas on what to try next.

Are you using the production environment or the demo environment?
I suspect that what's happening is that you are getting them mixed. As the baseUrl should not be demo.docusign.net etc. if you're using production (as indicated by your na3.docusign.net address) but you must ensure that the same account/user from production is also used.
So, the 4 things to check:
userId
accountId.
baseURI
authURI (account-d.docusign.com vs. account.docusign.com)
All of these should match and be for the same account in the same env.

Force a Kerberos or NTLM logon to an Active Directory domain

Can someone please assist with the following question
I want to be able to force either an NTLM logon or Kerberos logon to an Active Directory Domain controller as a separate user principle
Initially, I simply tried the Windows NET command as follows
net use \DCName\Sharename /user:DomainName\Username password01
and
net use \10.10.10.10\Sharename /user:DomainName\Username password01
the first one for Kerberos as the SPN (service principal name) can be obtained and therefore the hash to use with Kerbberos ticket encryption
The second one for NTLM as no SPN can be retrieved based on IP address and therefore fall back to NTLM
I have had very mixed results with the above, therefore I want to look for an alternative method (as I need to feed in lots or username and password to create lots of logons at the DC e.g. Kerberos or NTLM at will)
So next I tried
[system.reflection.assembly]::LoadWithPartialName('System.DirectoryServices.AccountManagement')
$D = [system.DirectoryServices.AccountManagement.ContextType]::Domain
$PC = [system.DirectoryServices.AccountManagement.PrincipalContext]$D
$M = [system.DirectoryServices.AccountManagement.ContextOptions]::Negotiate
$PC.ValidateCredentials('User01','Password01',$m)
However as one might imagine this only validated the username password combination it did not create a Kerberos TGT for the user for example (which is what I want to do when forcing a kerberos logon)
So my question is please, if there a .NET namespace when given a know username and password you can force the issuance of a TGT (for Kerberos authentication) or NTLM token, logon ?
Thanks very much in advance
EB

Why exactly are you wanting to do this?
Windows really doesn't want you to specify what protocol to use and instead just wants you to use Negotiate so it can safely move to better and more secure protocols without impacting apps.
That philosophy has mostly bubbled up through the major frameworks, so you're not going to get dedicated API's for each protocol.
That said, you can call directly in to SSPI specifically passing in "Kerberos" or "NTLM".
The gist of this is:
Client:
AcquireCredentialsHandle(..."Kerberos"...) ->
InitiateSecurityContext(..."spn/kerb.host"...) => server
Server:
AcquireCredentialsHandle(..."Kerberos"...) ->
AcceptSecurityContext(...iscTicket...)

ASP.NET cookies doesn't appear to be set when on IIS

I have an rather simple ASP.NET application that sets a cookie (actually 2) after a user has logged in.
This all works fine in any browser (I tested with IE, Chrome and Firefox) when I'm on my local machine running the app from VS2015 (aka IIS Express).
I can read the cookie as expected and I can also check the browser cookie collection and see that my cookie is there.
However, when I publish my project and bring it to a remote IIS (8.5 I believe, Windows Server 2012 R2) it doesn't work anymore.
I would provide some further information if only I knew what to provide - I have no idea what would be of interest in this regard for anyone trying to help me out - so I'm aware that I probably need to provide some extra information, I just don't know what :)
Please let me know how I can help you help me (and whoever might have the same issue).
UPDATE:
I didn't add the cookie code because it appears to be working (at least on my local IIS Express), but maybe I should be setting more of the cookie attributes for it to work on the remote IIS as well?
Setting the cookie
HttpCookie cookie_cusr = new HttpCookie("app_portal_cusr", JsonConvert.SerializeObject(cusr));
cookie_cusr.Expires = DateTime.Now.AddYears(30);
context.Response.Cookies.Add(cookie_cusr);
Reading the cookie (ClientUser is a custom class)
ClientUser cu = JsonConvert.DeserializeObject<ClientUser>(Request.Cookies["app_portal_cusr"].Value);
The application doesn't throw any exceptions - the cookie is just not set as in, it doesn't exist when i check the browser cookie collection and also when my code tries to read it (I check for NULL or it would actually throw an exception I assume).

How can I convince Internet Explorer to allow authentication as another user?

Thanks for reading and for your thoughts; this is a hairy problem, so I thought I'd share to see if it is actually a fair challenge for more seasoned developers than ourselves.
We're developing a web application for a corporate Microsoft Active Directory environment, and we use Windows Authentication provided by IIS to authenticate users for single-sign-on, alongside Forms Authentication. I know IIS complains when both are enabled, but it works very well, and every site we've deployed at has had no weird quirks to work around - until now.
The new site has "shared" machines, logged in permanently with a generic account that has read-only access to the applications they need to use. This means that we can't differentiate between users who should have different permissions to the application; we need some way of prompting the user for authentication details.
First try was some serious googling; nobody else in the world seemed to have our problem except for a few misguided souls who had asked questions into the ether and received no response.
After a bit of brainstorming and nutting out the way IIS's authentication works, it seemed that the most straightforward way to approach the problem was to issue a 401 Unauthorized in response to a user known to be a shared account. Initial tests here seemed fruitful, yielding successful changes of username inside the browser, however a prototype at the site did not prompt for credentials, and the browser kept the same account details. We also hit on the IE-specific javascript
document.execCommand("ClearAuthenticationCache")
which, again, worked in the lab but not onsite. Further experiments with IE security settings onsite revealed that the browser would automatically reauthenticate if the webapp site was excluded from the Intranet Zone, regardless of the method used to trick the browser into prompting the user for new account details.
Now we're stuck. We've got workaround options for getting it going on time, but they're definitely not the "right" answers:
require users to log out of the shared account before logging into our app (...yuck)
exclude our webapp from Intranet Zone on all machines
provide a non-SSO login service for users
I'm convinced that there's a canonical way to do this - a known pattern, a common base problem that's already been solved, something like that - and I'm very interested to hear what sort of inventive methods there are to solve this sort of problem, and if anyone else has actually ever experienced anything remotely like it.

We ended up settling on a solution that submits a query to the LDAP directory the server knows about. It means having to accept the user's password, but no other solution was solid enough to run in a production environment.
Hopefully this helps someone. .NET Framework 3.5+ required.
using System.DirectoryServices.AccountManagement;
private static bool IsLdapAuthenticated(string username, string password)
{
PrincipalContext context;
UserPrincipal principal;
try
{
context = new PrincipalContext(ContextType.Domain);
principal = Principal.FindByIdentity(context, IdentityType.SamAccountName, username) as UserPrincipal;
}
catch (Exception ex)
{
// handle server failure / user not found / etc
}
return context.ValidateCredentials(principal.UserPrincipalName, password);
}

Could you not create a page to which the shared accounts are denied access. Then do a redirect to that page, with a return URL encoded in the query string, at any point where you need the user to reauthenticate with a non-shared account? This should trigger the browser to put up the usual login dialog.
After the user reauthenticates, the new page should just redirect back to the return URL in the query string.

Setting up OpenID Provider with SubDomains Identifiers using DotNetOpenAuth

I am currently trying to implement an OpenID Provider on my own domain name.
Thus, I would like the OpenID Identifier of a user to be user.example.com instead of the default example.com/user.aspx/user..
Is it possible for DotNetOpenAuthto do that? If so, roughly what changes do i need to make?

Yes, it's absolutely possible.
Configure your DNS and web site(s) and IIS to actually respond to user.example.com.
Place a default.aspx file such that it responds to requests for that domain, and make that URL an OpenID Claimed Identifier by placing the tags in it that you find in the user.aspx sample. Be sure in those tags that point to your OP Endpoint that it uses the absolute URL (which may be http://www.example.com/provider.ashx)
Modify your provider.ashx (or server.aspx, or MVC action, whatever you're using for your OP Endpoint) to be willing to send assertions for user.example.com
And you're done. I haven't gone into great detail on these steps because it's the same steps you take when you customize the URL of your claimed identifiers in any way -- special host name or not. The only really special step is #1: Configuring IIS. To accept any random host name requires special DNS configuration, but since it's just your own user name you can just hard-code your username into DNS.