#33 Help users rejected by server with 404 - wrong SIP URI

Stefan Becker

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

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:

givenName . sn + @COMPANY.COM


  • Stefan Becker
    Stefan Becker

    example LDAP code

  • Stefan Becker
    Stefan Becker

    The attached code is ready to be integrated. Just UI & i18n texts are missing.

  • pier eleven
    pier eleven

    I'll try to build and test when have access to AD at work

  • pier eleven
    pier eleven

    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.

  • Stefan Becker
    Stefan Becker

    - 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????)

  • pier eleven
    pier eleven

    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?

  • Stefan Becker
    Stefan Becker

    25% users which will get automatic help (I sincerely doubt your calculation though).