Only Administrators can log in

Guest

Hi Yvette,

thanks foy your feedback. I've tried exactly the procedure you've described but unfortunately, the problem remains the same.

So we're still a bit lost and think about replacing ProGet with a file share since it's currently just unusable :-(

Guest

Seems users with LegacyPassword_Indicator set to "Y" in the ProGet DB Users table can login, the Users with LegacyPassword_Indicator = "N" cannot. What is a legacy password? What can be the problem?

We changed the way hashing was performed in 3.5, so a Legacy Password is one that's hashed in a pre-3.5 manner. When a user logs-in with a Legacy Password, the existing password is re-hashed, saved, and the LegacyPassword_Indicator is set to N.

It's possible there's a bug with this behavior, but this would have impacted a lot of other users too, and this is the first report.

I suspect it's related to privileges, so I would diagnose by giving everyone admin, or a specific user all privileges, then working down from there. You can also try to create a new user, and then see if that user can log-in with admin privileges.

Guest

May it be a problem that I've jumped over some releases and updated from 3.4.7 to 3.8.6 directly. I did that end of last week so it could be possible that the update is related to the issue.

Guest

Maybe there is a problem in BuildInDirectory.TryGetAndValidateUser? What happens to users with a non-legacy password (= with an Indicator "N") there?

Guest

I'm not sure, that method hasn't changed since 3.5; unfortunately we can't test/validate this quickly or easily, but here is the code if anything comes to mind:

    public override IUserDirectoryUser TryGetAndValidateUser(string userName, string password)
    {
        if (string.IsNullOrEmpty(userName))
            throw new ArgumentNullException("userName");

        try
        {
            var userInfo = StoredProcs.Users_GetUser(userName).Execute();
            var user = userInfo.Users.FirstOrDefault();
            if (user == null)
                return null;

            if ((YNIndicator)user.LegacyPassword_Indicator)
            {
                if (StoredProcs.Users_ValidateLogin(userName, password, null).Execute() == YNIndicator.No)
                    return null;

                SetPassword(userName, password);
            }
            else
            {
                using (var rfc2898 = new Rfc2898DeriveBytes(password, user.Salt_Bytes, 10000))
                {
                    var bytes = rfc2898.GetBytes(20);
                    if (!StructuralComparisons.StructuralEqualityComparer.Equals(bytes, user.Password_Bytes))
                        return null;
                }
            }

            return new BuiltInUser(user, userInfo.UserGroups);
        }
        catch (Exception ex)
        {
            Log("TryGetAndValidateUser: " + ex.ToString());
            return null;
        }
    }

This is the set method...

    public static void SetPassword(string userName, string password)
    {
        using (var rfc2898 = new Rfc2898DeriveBytes(password, 10, 10000))
        {
            var bytes = rfc2898.GetBytes(20);
            StoredProcs.Users_SetPassword(userName, bytes, rfc2898.Salt).Execute();
        }
    }

Guest

First thing to mention is that this is different from what was delivered with 3.8.6. Not sure if that makes a difference but it is.

My guesses:

if ((YNIndicator)user.LegacyPassword_Indicator) checks if the LegacyIndicator exists at all (so checks if it's a 3.5 or later version). In my installed 3.8.6, this part is if (user.LegacyPassword_Indicator != null).
if user has a legacy password, password is upgraded (SetPassword...)
If user has no legacy password (Indicator "N"), null is returned:

if (StoredProcs.Users_ValidateLogin(userName, password, null).Execute() == YNIndicator.No)
return null;

As I see, null is also returned if user is null (if (user == null) return null;) or the password is wrong (if (!StructuralComparisons.StructuralEqualityComparer.Equals(bytes, user.Password_Bytes)) return null;). So returning null seems to mean "No valid login". And it seems that users with an Indicator "N" (these users have the problem in my installation) always get a return null in versions 3.5 and later?! So that may be the problem. What do you think?

Guest

That logic seems correct... we can repro this issue only if the users are not granted the "General_ViewHomePage" task.

Once a user has a failed login, can they browse directly to a particular feed if it's typed into the URL, e.g. http://{proget-server}/feeds/{feed-name} ?

Guest

Yes, navigating to the feed directly works after the failed login.

Guest

The users who cannot log in are mapped to the roles "Package Consumer and Adder" and "Package Consumer".

From the ProGet DB:

Roles Table:

Role_Id Role_Name

...

9 Package Consumer and Adder

8 Package Consumer

Tasks Table:

Task_Id Task_Name Feed_Scopeable_Indicator

...

28 General_ViewHomePage N

RoleTask Table

Role_Id Task_Id

...

8 1

8 2

8 5

8 28

9 1

9 2

9 4

9 5

9 28

Guest

Are those privileges assigned to a feed? If so, the General_ViewHomePage task will be ignored.

Make sure to grant General_ViewHomePage at the SYSTEM level and not scoped to a particular feed, that should resolve the issue.

Guest

Yes, the privileges are scoped to a certain feed. You're right, As soon as i scope to "All Feeds", login works. That's great!

I'm still abit confued about how to limit some people to only one feed. They should be able to Add, View, Download packages of one feed only (including uploading packages using the web ui). Other feeds should not be visible to them. How to achieve that without scoping my privilege to a certain feed.

What I didis to create a new Role "HomePageViewer" Role with only the General_ViewHomePage Task. Then, I've created two assignments for my ProductDevelopers group:

Principal:ProductDevelopers, Role:Package Consumer and Adder, Scope: MyFeed
Principal:ProductDevelopers, Role:HomePageViewer, Scope: (System)

Would that be a recommended way or did I think too complicated?