#33 Help users rejected by server with 404 - wrong SIP URI
When the user has been rejected by the server with 404 we know at least these:
- the login credentials are correct (would get 401 otherwise)
- the SIP URI is either wrong
[ - or the user isn't allowed to use OCS. Extremely rare case, why would he try to use SIPE then?]
Currently every 404 creates a new thread in the support forum. Instead Sipe should help the user to at least to try to fix the problem himself. The necessary information can be retrieved via LDAP from the users AD server.
Known information provided by user
xxxxxx@COMPANY.COM
DOMAIN\ACCOUNT
<password>
First LDAP operation: request root base:
$ ldapsearch -LLL -h DOMAIN.COMPANY.COM -b "" -s base defaultNamingContext
-> defaultNamingContext: DC=XXX,DC=COMPANY,DC=COM (example)
Second LDAP operation: bind with users' credentials and retrieve information from account:
$ ldapsearch -LLL -h DOMAIN.COMPANY.COM -D "ACCOUNT@DOMAIN.COMANY.COM" -W -b "<defaultNamingContext>" -s sub "(&(ObjectClass=user)(samaccountname=ACCOUNT))" msRTCSIP-PrimaryUserAddress mail givenName sn
If LDAP succeeds (and ONLY THEN!!!) present to the user
- if msRTCSIP-PrimaryUserAddress exists: "your sign-in name is xxx"
- otherwise "can't determine your sign-in name. Please try one of these:
mail
ACCOUNT@DOMAIN.COMANY.COM
givenName . sn + @COMPANY.COM
ACCOUNT@COMPANY.COM"
example LDAP code
The attached code is ready to be integrated. Just UI & i18n texts are missing.
I'll try to build and test when have access to AD at work
Well I'm able to retrieve SIP URI on both test and production AD interactively (ldapsearch):
ldapsearch -LLL -h cosmo-ocs-r2.cosmo.local -D "alice@cosmo.local" -W -b "DC=cosmo,DC=local" -s sub "(&(ObjectClass=user)(samaccountname=alice))" msRTCSIP-PrimaryUserAddress mail givenName sn
...
dn: CN=Alice Alisson,CN=Users,DC=cosmo,DC=local
sn: Alisson
givenName: Alice
mail: alice@cosmo.local
msRTCSIP-PrimaryUserAddress: sip:alice@cosmo.local
But still many questions to the approach:
1) Input parameter: Username/password. There is SSO (Single-Sign On option), when user doesn't provide Username/password at all. That's the point of SSO.
Note: Username actually accessible through env var %USERNAME% (or %USER%) on Windows.
2) AD server should be resolved somehow. Again there is env var on Windows %USERDNSDOMAIN% for default domain.
For me actually DOMAIN+COMPANY.COM (in terms of this thread) doesn't point to AD. It's something else added in between.
3) No official binary openldap distribution for Windows. I.e. it's hard to find, not up to date, no sync with releases. I've experimented on Linux with the above. (I seems had enough of adopting GMime on Windows.)
I'm saying that it's more problems than benefits to my mind.
Simple:
- if openldap is not available then the code is flagged out.
- If LDAP can't be accessed for any resaon then nothing is shown to the user (I thought this was clear from the example code????)
Not resolving AD address properly would reduce successful cases in half.
Not supporting Windows users will reduce user base of the functionality to other half.
What's the point to target only 25% of users?
25% users which will get automatic help (I sincerely doubt your calculation though).