Justin,
I found notes from and old lengthy PMR from IBM, see below.
For mapped drives, only system name will work, IPs no longer.
Which keytab principal is used for ODBC?
PMR notes.
Regarding making kerberos connections to the IP address, it appears that (although this has worked in the past) at some point Microsoft clients stopped using Kerberos for connections established via IP address and current Microsoft clients appear to only make Kerberos connections only for system names that resolve in DNS. So, the IP address is probably not going to work. I found the following article on support.microsoft.com:
https://support.microsoft.com/en-us/help/322979/kerberos-is-not-used-when-you-connect-to-smb-shares-by-using-ip-address
If you need additional confirmation, please contact Microsoft.
Regarding encrypted password connections to IP addresses (which you and I also talked about) the developer tells me that NetServer does bind to all TCP/IP interfaces that are active at the time when NetServer starts. Clients should be able to access NetServer, using encrypted passwords, through any interface with a network path from the client to the server.
Regarding which Service Principals are necessary:
(HOST) The HOST form of the principal name is obsolete. It was used by Windows 2000, and is still part of the NetServer documentation and configuration wizard for compatibility sake. If you are only running 'currently in service' Windows clients, the HOST principals won't ever be used and can be removed.
(cifs) Only the service principals for names that you plan to connect to using Kerberos are necessary. For example, if the Qname (QPencor name) is unused, the principals can be removed. IP address can also be removed, since currently supported Microsoft clients do not appear to support kerberos connections using IP address.
The developer stated that the NetServer (NETSERVER06) name may or may not work in current environments since it is a NetBIOS name. If it doesn't work, he said it can be removed. When he told me that, one thing came to mind. Since kerberos is DNS based, I wonder if a DNS entry could be added (on the DNS) for the NetServer name. I can't guarantee that would work, but it's something you could try if you wish. If it does work please let me know and I'll add that little trick to our documentation.
The developer is reluctant to advise anyone to remove the fully qualified principal name because behavior may vary based on your DNS configuration. It is advised that you keep both the Pencorp06 and Pencorp06.pencorp.com principals at a minimum.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Justin Taylor
Sent: Wednesday, August 30, 2017 7:47 PM
To: Midrange Systems Technical Discussion
Subject: Re: EIM SSO expired password issues
ODBC works with EIM with the iAccess client (both old & new style).
We use EIM for:
5250
Apache
ODBC
NetServer
QNTC
________________________________
From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Sent: Wednesday, August 30, 2017 5:28 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: EIM SSO expired password issues
Hi Paul
This is valid behavior.
Basic concept - SSO means that a password is not used or needed. It is not even considered when authenticating, since SSO assumes that authenticating is done by the 3rd-party trusted Kerberos ticket manager, which is Windows in your case.
So since this is valid behavior, I would say that your regular user profiles should all be set to PASSWORD(*NONE) - this prevents the use of this profile for things like ODBC, say, as I understand it.
There are other considerations I won't speak of, such as profiles you need for access to the machine when Kerberos is broken.
HTH
Vern
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
