Created attachment 976317 [details] Pidgin Debug Log File Description of problem: Version-Release number of selected component (if applicable): pidgin-sipe-1.18.4-1.fc21 How reproducible: Steps to Reproduce: 1.Install pidgin, pidgin-sipe-1.18.4-1.fc21 and purple-sipe-1.18.4-1.fc21.x86_64.rpm 2.Try to connect 3. Actual results: Connection failed Expected results: Connection successful Additional info: I upgraded to pidgin-sipe-1.18.5-1.fc21 and purple-sipe-1.18.5-1.fc21.x86_64.rpm, it doesn't work. I installed F20 packges (purple-sipe-1.18.5-1.fc20.x86_64 and pidgin-sipe-1.18.5-1.fc20.x86_64) and it works.
F21+ uses gssntlmssp and not the internal NTLM implementation anymore. Please provide the same debug log for the F20 version, to prove that authentication works with the old internal NTLM implementation
Created attachment 976327 [details] Debug file from pidgin-sipe F20 I have truncated the log file. Please tell me if you need the unabbreviated version.
Created attachment 976570 [details] decoded NTLM response from internal NTLM implementation
Created attachment 976571 [details] decoded NTLM response from gssntlmssp NTLM implementation
Comparing the two debug logs: the only real difference is the NTLM response. Comparing the two decoded NTLM responses shows IMHO only one real difference: - working: user@domain - not working: DOMAIN & user (without domain) Re-assigning to gssntlmssp for further analysis, because this isn't caused by SIPE itself. Maybe Simo has an idea for a work around. My only idea would be to try "/user@domain" (notice the leading "/" which forces an empty domain) as SIPE login name.
uhm the capitalized domain name look suspicious, it means a DNS domain name has been used instead of a NETBIOS domain name. You can try using user\@domain.tld as the username, this will cause gss-ntlmssp to consider the whole string as the username and not split off the domain. The other option is to user user@domain or DOMAIN\user where domain is the NETBIOS name of the domain not the DNS name. Usually the NETBIOS name is the first part of the DNS domain until the first dot.
It doesn't work better with user\@domain.tld or /user. It works with DOMAIN\user.
Created attachment 976772 [details] Log with \user@domain
Created attachment 976773 [details] Log with user\@domain.tld
Created attachment 976774 [details] Log file with DOMAIN\user Here, the sAMAccountName is used instead of the UserPrincipalName.
(In reply to Kevin Cousin from comment #7) > It doesn't work better with user\@domain.tld SIPE recognizes "/" and "\" as domain separator: (11:40:20) sipe: sipe_purple_login: username 'kcousin,kcousin\@globalsp.com' (11:40:20) sipe: sipe_purple_login: login 'kcousin\@globalsp.com' (11:40:20) sipe: sipe_purple_login: auth domain 'kcousin' user '@globalsp.com' In this case this leads to complete incorrect information being used (from decoded NTLM response): domain: globalsp.com@KCOUSIN host: PC-KCO-AMD What should work is a login name with TWO(!) "\": (13:10:34) sipe: sipe_purple_login: username 'kcousin,\kcousin\@globalsp.com' (13:10:34) sipe: sipe_purple_login: login '\kcousin\@globalsp.com' (13:10:34) sipe: sipe_purple_login: auth domain '' user 'kcousin\@globalsp.com' which leads to the following NTLM response: user: kcousin host: .... This is the same as from the internal NTLM implementation, except that the domain part is in upper case, but that shouldn't matter. > or /user. Again, the domain separator comes into play: (11:37:57) sipe: sipe_purple_login: username 'kcousin,/kcousin' (11:37:57) sipe: sipe_purple_login: login '/kcousin' (11:37:57) sipe: sipe_purple_login: auth domain '' user 'kcousin' i.e. this boils down to the same as login name "kcousin" > It works with DOMAIN\user. No surprise here, because that is the Windows AD way...
(In reply to Stefan Becker from comment #11) > What should work is a login name with TWO(!) "\": > > (13:10:34) sipe: sipe_purple_login: username > 'kcousin,\kcousin\@globalsp.com' > (13:10:34) sipe: sipe_purple_login: login '\kcousin\@globalsp.com' > (13:10:34) sipe: sipe_purple_login: auth domain '' user > 'kcousin\@globalsp.com' > > which leads to the following NTLM response: > > user: kcousin > host: .... > > This is the same as from the internal NTLM implementation, except that the > domain part is in upper case, but that shouldn't matter. The upper case is forced by SIPE GSSAPI code in src/core/sip-sec-gssapi.c:sip_sec_acquire_cred__gssapi(): (13:10:34) sipe: add_mech: added NTLM to mech set (13:10:34) sipe: sip_sec_acquire_cred__gssapi: username 'kcousin\@GLOBALSP.COM' (13:10:34) sipe: sip_sec_init_sec_context__gssapi: started In this case the second conditional branch is used: /* Construct user name to acquire credentials for */ if (!is_empty(domain)) { /* User specified a domain */ gchar *realm = g_ascii_strup(domain, -1); username_new = g_strdup_printf("%s@%s", username, realm); g_free(realm); } else if (strchr(username, '@')) { /* No domain, username matches XXX@YYY */ gchar **user_realm = g_strsplit(username, "@", 2); gchar *realm = g_ascii_strup(user_realm[1], -1); /* * We should escape the "@" to generate a enterprise * principal, i.e. XXX\@YYY * * But krb5 libraries currently don't support this: * * http://krbdev.mit.edu/rt/Ticket/Display.html?id=7729 * * username_new = g_strdup_printf("%s\\@%s", */ username_new = g_strdup_printf("%s@%s", user_realm[0], realm); g_free(realm); g_strfreev(user_realm); } else { /* Otherwise use username as is */ username_new = g_strdup(username); } SIPE_DEBUG_INFO("sip_sec_acquire_cred__gssapi: username '%s'", username_new);
From GSS-NTLMSSP it is SIPE that is doing "too much" as the GSSAPI mechanism knows how to handle the following forms natively: input -> domain / username domain\name -> domain / name name@domain -> domain / name name\@domain.tld -> <null> / name I could add support for treating name as an enterprise name as well given . is an invalid chracter for a NETBIOS domain name (IIRC). But I think for this bug it is SIPE that needs to decide how to properly format and pass the name to GSS-NTLMSSP in the Enteprise/UserPrincipalName case based on the user's input/configuration.
(In reply to Simo Sorce from comment #13) > From GSS-NTLMSSP it is SIPE that is doing "too much" as the GSSAPI mechanism > knows how to handle the following forms natively: > input -> domain / username > domain\name -> domain / name > name@domain -> domain / name > name\@domain.tld -> <null> / name Sorry, can you be more specific about "doing too much"? All of the above is supported/not prevented by SIPE. Please remember that the up-case conversion of then domain stems from the long mail thread between you, David and me about cleaning up the GSSAPI support in SIPE. The first version of the code I quoted is from David's test implementation. Are you now trying to tell me that up-case conversion of the domain is incorrect? AFAIR it was required by Kerberos and with GSSAPI-only SIPE no longer gets to decide what authentication backend is selected.
By too much I mean that, for example, you split on \ unconditionally w/o checking if it is an escape for @. But it is not for me to decide what SIPE should expose to the user and how to parse it. Perhaps it is just a matter of handling domain names witrh a . in them in a smarter way (they can't be NETBIOS names) and just recompose back such a user string and pass user\@domain.tld in that case ? For Kerberos unconditionally converting the realm to upper case would break the (admittedly unlikely) case where someone used a lower case realm name with a trusting MIT KDC. AD doesn't care because AD is case insensitive.
(In reply to Simo Sorce from comment #15) > By too much I mean that, for example, you split on \ unconditionally w/o > checking if it is an escape for @. But it is not for me to decide what SIPE > should expose to the user and how to parse it. This bug report is for the login name "user", ie. SIPE doesn't parse anything in that case. Just the "domain.tld" part gets upper-cased. The only change I can imagine is that the callers of sipe_core_allocate() would flag out any login name -> domain/user parsing when HAVE_GSSAPI_ONLY is defined, i.e. auth_domain would always be NULL and user would always be the same as the login name. But again, this wouldn't help in this reported failure case. > Perhaps it is just a matter of handling domain names witrh a . in them in a > smarter way (they can't be NETBIOS names) and just recompose back such a > user string and pass user\@domain.tld in that case ? Why would SIPE need to know/do that if this only applies to gssntlmssp? SIPE just calls GSSAPI, it doesn't know nor care that gssntlmssp sits in the backend of that call. > For Kerberos unconditionally converting the realm to upper case would break > the (admittedly unlikely) case where someone used a lower case realm name > with a trusting MIT KDC. AD doesn't care because AD is case insensitive. Well, OCS/Lync is a M$ product and therefore will always use AD for Kerberos/NTLM authentication. In my experience with AD, "DOMAIN" always works, whereas "domain" may or may not work.
(In reply to Stefan Becker from comment #16) > (In reply to Simo Sorce from comment #15) > > By too much I mean that, for example, you split on \ unconditionally w/o > > checking if it is an escape for @. But it is not for me to decide what SIPE > > should expose to the user and how to parse it. > > This bug report is for the login name "user", ie. SIPE doesn't > parse anything in that case. Just the "domain.tld" part gets upper-cased. > > > The only change I can imagine is that the callers of sipe_core_allocate() > would flag out any login name -> domain/user parsing when HAVE_GSSAPI_ONLY > is defined, i.e. auth_domain would always be NULL and user would always be > the same as the login name. But again, this wouldn't help in this reported > failure case. Ok so do you suggest that GSS-NTLMSSP gets smarter and automatically treats a domain with a . in the name as an enterprise name on its own ? I guess I can do that if it helps.
(In reply to Simo Sorce from comment #17) > Ok so do you suggest that GSS-NTLMSSP gets smarter and automatically treats > a domain with a . in the name as an enterprise name on its own ? I guess that is currently the only way, as SIPE can't convert "@" to "\@" due to the missing support in krb5 (see the comment in the quoted code).
Unfortunately I just chcked the spec and '.' are technically allowed in NETBIOS names, however given the usability issues I think it is ok for those cases to tell peolple to use the DOMAIN\user form instead of user@DOMAIN.
(In reply to Simo Sorce from comment #19) > however given the usability issues I think it is ok for those > cases to tell peolple to use the DOMAIN\user form instead of user@DOMAIN. SIPE documentation already recommends that: https://sourceforge.net/p/sipe/wiki/How%20to%20setup%20an%20account/#login
I made a test build with a patch to implement the proposal in comment #17 Kevin can you grab the righ tF21 package from the URL below, restart Pidgin and tell me if it now works with your original settings ? https://copr.fedoraproject.org/coprs/simo/gssntlmssp/build/66423/
It works now, thanks for you work !
(In reply to Kevin Cousin from comment #22) > just a typo It works now, thanks for your work !
(In reply to Simo Sorce from comment #13) > From GSS-NTLMSSP it is SIPE that is doing "too much" as the GSSAPI mechanism > knows how to handle the following forms natively: After pondering the consequences of this discussion by reading through the code again and trying some changes, I realized that this doesn't hit the root cause. The problem is another old, now obsolete, assumption in the SIPE code: the parsing of the login name is done at the wrong place. I have opened https://sourceforge.net/p/sipe/feature-requests/80/ for the cleanup.
gssntlmssp-0.5.0-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gssntlmssp-0.5.0-3.fc21
Package gssntlmssp-0.5.0-3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gssntlmssp-0.5.0-3.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0395/gssntlmssp-0.5.0-3.fc21 then log in and leave karma (feedback).
gssntlmssp-0.5.0-3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.