× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It's just for all userprofiles. Expiration is *nomax, and Netserver access
is proper. There are no locked accounts in Netserver.
I believe the cause must be at the Windows side, but I don't understand why
Windows 2008 / Win 7 keep offering an NTLMv2 hash value, even when the
domain policy tells them to fall back to the LANMAN password.
For example when I create a windows account for QSECOFR all authenticates
well as long as the password is not mixed case. When it is set to mixed
case, the authentication fails because Windows still offers the mixed case
password to the i instead of the LANMAN hash.


Regards,
-Arco



2010/9/28 Jack Kingsley <iseriesflorida@xxxxxxxxx>

Is this a new user that you setup recently, what is the password expiration
interval setup as, do they have proper security access in netserver shares
setup.

On Tue, Sep 28, 2010 at 1:05 PM, Arco Simonse <arco400@xxxxxxxxx> wrote:

Hi folks,

Here we have a problem for which I cannot find a solution, even not with
help of IBM and MS.
So I thougth I'll ask the experts.

Given situation is that we have a new Windows domain running on Windows
2008
R2 SBS Server (x64) in which domain a Power 520 with V6R1M1 will reside.
But
we have a problem to authenticate to the i when we try to connect to an
IFS
share with a Windows user account that has a mixed case password. The
standard authentication protocol of Win2008 uses NTLMv2, which is not
understood by the i, since it is running at QPWDLVL 0.
IBM advised to change the Windows policy settings for Network security:
"Do not store LAN Manager hash value on next password change" to
"Disabled"
"LAN Manager authentication level" to "Send LM & NTLM - use NTLMv2
session
security if negotiated"

These settings should achieve that the Win2008 also should send the
LANMAN
hash value when the password is mixed case.
But it does not do that. IBM was helpful on this by analyzing network
traces, And it turned out that even with these policies set, the Win2008
server tries to connect with the NTLMv2 security. This also happens for a
Windows 7 machine in the domain. In the domain is also a Windows 2003
server, from which everything works seamless. It seems really a
Win2008/Win7
problem.

So we also asked to Microsoft. They looked at the case and came back with
very little information, and saying this is "Working as designed voor
Windows 2008 R2".

This is really annoying. I don't want to raise the QPWDLVL of the i (at
least not now) because it has to talk with another i in another domain,
and
I don't want to disturb that. And IBM tells that raising the QPWDLVL is
easy, but going back is painful.

Has someone seen the same behaviour in their shops?

Many thanks,
-Arco
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.