Debug why a user cant login

One of our users cant login either using WIA or username and password. Is there any logs that I could look at to find out why his credentials are being declined? Thanks,
-Michael

Product: ProGet
Version: 3.8.0

I'm afraid there's not additional debugging information available.

It could be that the password is incorrect, the password has expired, etc.

The issue is with ProGet not the account. That's why I am looking for logs. Is this something you could add to a future version?

Unfortunately, there's nothing we can log.

We simply ask Active Directory for a user with the specified name and password (using DirectoryEntry), and the DirectorySearcher either returns a user entry, or not. If there was an error while attempting the operation, then it would have been logged.

If you're seeing that this is working with some accounts, but not others, then the issue is most certainly with the account.

Since the account works fine with everything but ProGet, the only way to debug is to find out why ProGet rejects the credentials.

In that case, you'll need a third-party that can operates between the API layer we use and your Active Directory. Microsoft provides Insight for Active Directory, which should be helpful on this.

Is there something special I have to do first to get that to work? I ran it with admin privileges on the server with ProGet then logged into ProGet from that same machine and nothing was logged.

Make sure to restart the ProGet web server (IIS), then AdInsight should start intercepting calls .

I restarted the ProGet service and still get nothing in Insight.

The user was granted access via group membership but can only login if he is granted access to the repo by name. Is it possible there's an issue with ProGet's handling of AD groups?

This could be caused by a lot of things. If you're unable to get an AD Interception tool working, then the next best thing is to expierement and find what works, and what doesn't. That will help isolate where the problem is.

The most likely scenario is using a Distribution Group, not a Security Group.

The secnond likely scenario is that the user ProGet is running on does not have the ability to enumerate that user's groups. That will silently prevent membership detection.

The third most-likely secnario is that the credential not have read-access to that group; that will also silently prevent membership detection.

It's possible to configure a single domain to prevent object access like that, but it's quite common in mulit-domain/forest setups when trusts are not configured properly.

Thanks Alana,
The group has many members, only one of which can't login. ProGet runs on the same user account as all of other servers; none of the other servers have this problem with this user. I'm not sure what you mean in the third scenario.
-Michael

Short of running something to intercept the LDAP queries and diagnosing from there, there's nothing further we can do on the ProGet side.

One option is, we can share with you the user directory code that ProGet uses to query LDAP, and you can build a simple console application out of the code to see why it won't work for that user.

If that's a direction you'd like to go, please fill out the source request form, and we can send it along.

I have added another user to the group and ProGet doesn't allow him to login either. Is it possible ProGet caches group members and never checks for updates?

Any update on this? The server is useless if no one can login.

You can refresh the privilege cache by restarting the web application ( Admin > Advanced Settings > Save ).

Otherwise, it sounds like the root problem is "members of a certain group I've assigned privileges to in ProGet do not have those privileges"?

If that's the case, then the account that ProGet is running under does not have the ability to enumerate the user's group. There is no way to debug/log that, it simply returns an empty enumeration.

Not quite. It allows users to login that were in the group at the time ProGet was installed. Users added to that same group after that time cant login. the server has been restarted many times.

ProGet does not "sync" users/groups from Active Directory.

When an authenticated user (either via name/password or Windows Integrated Auth) accesses ProGet, AD is queried to discover the user's groups. This is cached in memory, but can be cleared by restarting the web application.

Then, permissions are resolved against the user and the groups returned from AD.

So, it really doesn't matter when they were added to the group.

Then what is the problem?

Short of running something to intercept the LDAP queries and diagnosing from there, there's nothing further we can do on the ProGet side.

One option is, we can share with you the user directory code that ProGet uses to query LDAP, and you can build a simple console application out of the code to see why it won't work for that user.

If that's a direction you'd like to go, please fill out the source request form, and we can send it along.

Since the product is unusable and you cannot support it, I would just like a refund. i dont have time to debug your code.

The problem is not our code or product, at all; we have 1000's of customers who have absolutely no problem whatsoever using this core functionality.

The problem is your network/configuration, and more specifically, your unwillingness to debug your own network/configuration problems. Expecting us to support your internal network configuration is like expecting Toyota to teach you how to drive a car.

That said, because not everyone knows how to set-up/configure a Windows domain, we offer a full-featured, 45-day trial just to make sure it works on their network. You took advantage of this trial... and then did an extended 90-day trial, and we provided you additional amount of support just getting basic things like IIS set-up.

We absolutely support our product, but you also need to be willing to troubleshoot your own network/configuration problems.

There are 10,000 machines and countless servers that authenticate against this domain and multiple servers that use the same groups I am trying to use in ProGet, why is your software the only one that doesn't work?

Short of using a crystal ball, we have absolutely no way of knowing why. It is, most certainly, a network/configuration issue on your end.

You need to provide actual information about your network/configuration and what specifically isn't working, in order for us (or anyone else) to provide assistance. This will require you to do additional troubleshooting/investigating to find out why some things work, and some things don't.

Your problem went from "one of our users cant login either using WIA or username and password" to "users to login that were in the group at the time ProGet was installed". Those are two very different problems, and as Alana explained, ProGet does not sync groups... so when the user was added to the group will have no bearing.

It's a very simple problem. The NuGet share is configured to allow all members of a certain group read access. This worked during our trial. Since we purchased the license, we added more people to that group. None of the people added since purchasing the license can login. If I add that same user by name in ProGet, he can login. These users have no problem logging in into any other service. Unlike any other server I manage, ProGet provides no information whatsoever about why the login was denied. Normally software records the LDAP response code received from the server in the audit logs.

Unfortunately, there's nothing we can log.

We simply ask Active Directory for a user with the specified name and password (using DirectoryEntry), and the DirectorySearcher either returns a user entry, or not. If there was an error while attempting the operation, then it would have been logged.

You can, however, use a third-party tool that operates between the API layer we use and your Active Directory. Microsoft provides Insight for Active Directory, which should be helpful on this.

You recommenced ADInsight previously. It is an obsolete tool that is no longer maintained. It does not work in Windows 2008 R2 nor on machines with VMWare tools installed.