• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2477
  • Last Modified:

New AS400 Users cannot browse to a Windows file server share

I'm not sure if I need to ask this question here or on the windows platform, so here it is....New AS400 Users or users which we change their passwords (in both systems) cannot browse to a Windows file server (Windows 2003) share.  Background:  The windows server is a member server of our domain and the primary domain controller is a windows 2008 server.  The users profiles/passwords are synced in both systems.  This is not effecting "older" users; meaning we haven't made any changes to their windows or as400 profiles in a while.  When logged in as a new user (or one we have recently changed the password for), we try and use the qntc command and navigate to the file server and receive an 'object not found' error.  The permissions on the share are correct and these same users can browse to the share via windows without any problems.  I'm not sure what's wong here...I assume it's a windows problem (it usually is :) ) so I'm not sure where to go from here.  I thought it might be a wins/dns issue but found that navigating by ip resulted in the same error.  I also suspected LM authentication was disabled on the windows side.  I checked the group policy in windows and that setting was 'not defined.'  I also checked the local machines and made sure the local policy was disabled.  I can browse to a share on the primary domain controller without issue.

Any help would be greatly appreciated!
0
jellis0
Asked:
jellis0
  • 12
  • 10
  • +1
2 Solutions
 
Gary PattersonVP Technology / Senior Consultant Commented:
First, give us a hint at what may have changed in the Windows network recently?  New domain controller?  Upgrade a server?  Merge domains?

Next, once you add the 2003 server to QNTC using MKDIR, does it properly enumerate the shares on that server when you browse down into the server from WRKLNK?  Create a temporary unsecured share (Everyone) on this server.  Can you access it from one of the new profiles?

Next, look at the job logs on the failing jobs after getting an Access is Denied message (DSPJOBLOG) and post detailed messages (put the cursor on the message and press F1 to see message details).  Post the related detailed messages, please.

Most of time these problems come down to one of two issues (though there are exceptions):

1) Problems related to differences in case-sensitivity in passwords. As a quick test, set an upper-case password (hold down SHIFT and force it manually to upper case, don't assume that the system will do it for you) on the AS/400 account, and make sure and sync a matching upper case password on the matching Windows account, and see if access is restored.  IF you use some sort of automated password-synching tool, take a look and make sure it isn't screwing up password case somehow.  Has it been changed lately?

I've seen a similar problem when a client changed their QPWDLVL system value, making AS/400 passwords suddenly case sensitive.  At QPWDLVL 0 an 1, the AS/400 automatically maps all passwords to upper case, no matter how they are entered, so it was impossible to have a lower-case or mixed-case AS/400 password.  It isn't uncommon to have an AS/400 password exit program that captures passwords when the user enters them, and that then changes the Windows password to match.

Under QPWDLVL 0 and 1, the hypothetical password changing and synching program might take the new password that the user entered (in mixed case, perhaps) map it to upper case, and then change the Windows password to match.  

You mention, however, that you can browse to a share on the PDC (I assume you mean from the AS/400) without an issue.  So, this means that when the AS/400 makes a request for share access of the 2008 server, all is OK.  When the AS/400 makes the same request of the 2003 server, not so  much.  

If I understand your comment, this makes it less likely that the issue is case sensitivity.

2) SMB digital signatures being required by a providing authentication:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahq%2Frzahqproblemsqntc.htm

You mentioned that AS/400 and Windows passwords are "maintained in sync".  How?

Read these, and post the relevant settings:  QPWDLVL system value, Netserver configuration (also post your OS/400 version).  Also verify that the LCLPWDMGT parameter on the working and non-working profiles aren't different for some reason.

http://www-01.ibm.com/support/docview.wss?uid=nas17d5a24100f2671648625756a006353a1
http://www-01.ibm.com/support/docview.wss?uid=nas10cc53e726bc9d4e0862572180076dc38
http://www-01.ibm.com/support/docview.wss?uid=nas183f03d61a99ec10286257117006036ed
http://www-01.ibm.com/support/docview.wss?uid=nas1864ff0c7897e74898625738b006163d2

Also, make sure you're up to date on PTF's.  For example, if you're on V6R1, there is a related PTF:

http://www-01.ibm.com/support/docview.wss?uid=nas32f97342614b68889862576ea006e0ff4

Finally, here are a few QNTC questions and answers from the past that might shed some light, and provide additional troubleshooting techniques:

http://www.experts-exchange.com/Programming/System/AS_-_400/Q_24496786.html
http://www.experts-exchange.com/OS/AS_-_400/Q_25045588.html

If all else fails, trace a working and non-working connection with WireShark (or your favorite network analyzer) and post a sanitized session here.

- Gary Patterson
0
 
jellis0Author Commented:
Thank you gheist and Gary_The_IT_Pro!  I will look into both of these and post more comments soon.  Gary, to answer what may have changed, I'm not sure, I just took over as a new Network Admin here a month ago.  I suspect this has been going on for quite some time, but we have just now discovered it.  I know not to long back (before I got here) they moved the domain controller to a Windows 2008 server.  I do know that we don't have any password syncing tool, I just manually sync the users passwords.  I'll post back soon.
-Josh
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
jellis0Author Commented:
Gary,
I also wanted to comment on this that you said:
"You mention, however, that you can browse to a share on the PDC (I assume you mean from the AS/400) without an issue.  So, this means that when the AS/400 makes a request for share access of the 2008 server, all is OK.  When the AS/400 makes the same request of the 2003 server, not so  much."
Yes, your assumptions are correct.  This comment is spot on.  The PDC is a Windows 2008 server and I'm still trying to track down when this was changed.  I got some additional information from one of our users this morning and they said they have been having the same problem since the day they started in November of 2010.
-Josh
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
Interesting.  Post the results of your investigation if you need more help.

- Gary
0
 
jellis0Author Commented:
Here are some results that I found:  When authenticating with a user who can successfully navigate to the share I see a success and a failure audi log.  The success log is when the AS400 sent the username in all lower case letters.  The failure log shows that the as400 sent the username in upper case letters.  
For a user that does not navigate to the share correctly I see two failures, both times the AS400 passed the username in upper case.  Is there a setting within the AS400 that is forcing new users to uppercase only?
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
On the as400 run this command and post results:

Dspsysval qpwdlvl.
0
 
tliottaCommented:
Is there a setting within the AS400 that is forcing new users to uppercase only?

In general, user profile names are upper-case.

Tom
0
 
jellis0Author Commented:
The value of that system setting is 0.  From our understanding, the AS400 will try and send the authentication request in all upper case and then try it in all lower case.  With new users and user where we have recently changed their password, it appears that the AS400 is sending both authentication attempts in upper case(so it appears from the windows security log).
0
 
jellis0Author Commented:
Here are the log entries from windows.  Note that there are two authentication attempts for each user.  One with all upper case one with all lower case.  The first two entries are from a user who could successfully browse to the windows file server.  Note the successful authentication request shows his username in lower case and the failed authentication request for the same user shows the username in upper case.  Entries 3 & 4 are from a user who could not browse to the windows share from the as400.  Note that both attempts to authenticate appear to be in upper case, going by the username.   winlogs.txt
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
And what is the LCLPWDMGT parameter on a working and non-working profile?  (DSPUSRPRF profilename) command.
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
BTW, it sounds like changing the Windows passwords to upper case would resolve the issue.

- Gary
0
 
jellis0Author Commented:
Both users from my last comment have the LCLPWDMGT parameter set to yes.
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
Can you also provide me the rest of the info I;ve requested in previous posts?  AS/400 OS version, Netserver configuration, etc.  IF you don't know how to gather any of it, let me know what you need help with and I can provide instructions.

- Gary
0
 
jellis0Author Commented:
Yeah I agree....we have an open ticket with IBM to see if they can determine if this is a bug or not.
0
 
jellis0Author Commented:
AS/400 OS Version 6 Mod 1.1  I asked our AS400 guy for the netserver config and he wasn't quite sure what you wanted.  Can you let me know where to go?
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
A few thoughts:

Is the Source Network address the same in all four audit log entries?

Also, read this:  http://support.microsoft.com/kb/102716

- Gary
0
 
jellis0Author Commented:
Those particular log entries are not from the same source network address, but just yesterday we did log in from the same box with working/non-working profiles and it made no difference.
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
OK, I looked it up.  

When QPWDLVL is "0", the AS/400 uses ONLY lower case passwords when authenticating to Windows.  

Does your Windows domain password policy encourage the use of upper case letters in passwords, by any chance?  It is very likely that this is what is happening.

This could happen if your Windows network was previously configured to allow lower case-only passwords, but was changed to require an upper case character (maybe when you installed Win 2008).  Your old users still have lower case Windows passwords, and can authenticate fine, but new users, and those that change their password are required to enter mixed case.

These mixed-case Windows passwords would then break the AS/400 authentication.

If so, you'll either have to change the Windows policy, or the AS/400 QPWDLVL setting, but you need to be VERY careful with changing the QPWDLVL setting, as it can have unintended consequences:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Frzamv%2Frzamvpasswdlvlchg.htm

- Gary Patterson

0
 
Gary PattersonVP Technology / Senior Consultant Commented:
BTW, good luck getting much help from IBM on this one.  There are things they do a great job with, but resolving cross-platform issues is not one of them, in my experience.

Prediction: They will recommend a list of related PTF's for your OS level, and if that doesn't resolve the issue, they will offer you "profe$$ional $ervice$ a$$i$tance in properly configuring authentication between the AS/400 and Windows".

<Rant>

Don't mean to be rude, but do you suppose he could be to take, what, 10 seconds? to google "netserver configuration" before asking me to do it?  I'm trying to help here (for free), and it is really  frustrating when the people that are getting paid to help won't even lift a finger.

</Rant>

- Gary

0
 
jellis0Author Commented:
LMAO on both points above!  I think I've found the issue, I will post back soon.  Thank you so much for all of your help!
0
 
jellis0Author Commented:
Gary,

I should have found this much earlier, but here it is.  So the article above, http://support.microsoft.com/kb/102716, gave me the info I needed.  With windows 2008 server nolmhash is enabled out of the box for its "local Security Ploicy".  Because it is the PDC it was not storing the LM hash version of the passwords in the AD Sam DB.  When I checked this setting a few days ago, I only checked all of the group policies not the local policy.  My fault.  The fix was to change this via a group policy to "disable," and then change my passwords in both systems (Windows and AS400).  When I changed the password in windows, it then stored the lmhash version of the password in AD.  I then authenticated to the as400 and browsed that 2003 file server without any issues.

Thanks again for all of your help!!!!!
0
 
jellis0Author Commented:
Check the local security policy for any server newer that windows 2003.
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
Glad you got it worked out.

- Gary
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 12
  • 10
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now