How to change a password? policy.conf updates break passwd on SunT1000 and Sun45

I have two Sparc Solaris 10 servers (a T1000 and an ultra 45) that I recently began to administer (after a long period of thinking I would never touch Solaris again).

One of the security requirements I need to do is update /etc/security/policy.conf to use sha-256. When I modify the policy.conf file to point to sha-256, I am able to successfully change passwords and I see that the /etc/shadow file gets correspondingly updated with the new algorithm (5$), but when I then try to logon through SSH, XServer, or locally, I get "password incorrect".

I am positive I am using the exact same string of characters for the password when I change it as the string I use for login. I suspect either it isn't getting hashed the same by login as it is by passwd, or possibly it's using something other than PAM to put it into /etc/shadow maybe?

These are my relevant entries in /etc/security/crypto.conf

1          crypt_bsdmd5.so.1
2a        crypt_bsdbf.so.1
md5    crypt_sunmd5.so.1
5          crypt_sha256.so.1 
6          crypt_sha512.so.1  

And here is the relevant entries in policy.conf

CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6
CRYPT_DEFAULT=5
#CRYPT_ALGORITHMS_DEPRECATE=__unix__

The old policy.conf

CRYPT_ALGORITHMS_ALLOW=1,2a,md5
CRYPT_DEFAULT=__unix__
#CRYPT_ALGORITHMS_DEPRECATE=

I've tried using different algorithms for the default (md5, 6) but no success with those either, I can change a password with passwd, then I can no longer authenticate to login as that user with the new or old password (and like I said, the shadow file is getting updated anyway so it couldn't be the old password, but I have tried it and am also positive I am using the correct old password)

I've also tried uncommenting the CRYPT_ALGORITHMS_DEPRECATE and setting it to __unix__ but I can ONLY authenticate with a password when the policy.conf is pointing to __unix__ and DEPRECATE line is commented out (and I have set the password using those settings). Based on online suggestions I've seen NIS,NIS+,LDAP, or PAM as possible issues but I am having difficulty figuring out if any of those are in play here.

I also saw a suggestion that you must delete the password that has an old algorithm before changing it so I tried that (passwd -d username, check shadow and it's gone, then passwd username). I've also tried a few combinations of rebooting after changing the policy.conf and using cryptoadm to restart... kcfd? I believe.

Does anyone have any idea what could be going on here? There is scant information online and it is all from 2015 or earlier (not that that matters, I assume most Solaris help was last decade, this security requirement might be new though).

Any help would be really appreciated. I managed to brick one of them because I forgot to change the policy.conf back to unix while I was tinkering with it and killed my root password. I think I have recovered from that before by going into single-user mode on via the ALOM but it has been so freaking long I don't quite remember, anyway, this question is mostly about how to get them into security compliance, not fixing my dumb mistake. I still have the other machine with the old policy.conf and he is fine.

Also posted to StackOverflow.

Hello,

Welcome ! We hope you enjoy your time here, and find this to be a friendly and helpful place.

I recall someone once posting a similar question a year or so ago, saying they were having trouble with using SHA256 on Solaris 10. The issue there turned out to be that they didn't have the requisite patch installed to enable SHA256 and SHA512 support in Solaris 10. Can you check that you have patch 140905-02 installed, and install it if you don't ? If that is already installed or if installing it doesn't help, then please get back to us and we can take things from there, as that's probably the first thing to check.

In addition to what @drysdalk said I would also add that you need to configure the old algo as DEPRECATE otherwise the new algo will only be used for new accounts. Existing accounts will still use the algo they had before.

Yes, patches are needed. (Just one??)

AFAIR with the required patches the following line is already there:
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6
And manually setting
CRYPT_DEFAULT=5
will use the long crypt for each new or changed password, but existing short crypts still work.

Hello and thanks!

showrev -p | grep 140905 returns nothing. These machines are not in an environment where they are connected to the internet so I will have to see what it will take to get that patch. I will note that we just did a round of patches and before the patches I did not have sha-256 or sha-512 in my crypto.conf. After the patches they had been added, which I assumed was what made them available. I'll see if I can locate 140905-02 somewhere and then get back to you guys.

Just to finish responding to everyone: I have set the DEPRECATE value to the __unix__ and then ran passwd on one of the user accounts and then couldn't log in with their account anymore (I then changed the policy.conf bak to the old setting using __unix__ and changed it again so it's still usable).

Also I did end up getting in the machine I had locked the root password on so I'm good to test on both machines.

It sounds like the consensus is that it is the patching level so I will try that route, neither machine has the 140905 patch according to showrev.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.