I will be speaking at DNUG47ONLINE
My session is “Setting up Jitsi authentication and customization”. July 2 at 16.30.
You can find the agenda of all the sessions here
My session is “Setting up Jitsi authentication and customization”. July 2 at 16.30.
You can find the agenda of all the sessions here
By default when you install Sametime Proxy 11 it will use self signed certificates. My peer HCL Ambassador Ales Lichtenberg has written a blog post, here, about how to use a CA issued certificate. In his article he uses the .pem format for the certificates; I found there is another way to do this using the pfx format for certificates.
Once you have the pfx file, and the relative password, is very easy to configure Tomcat to use it. Open the server.xml file in the sametimeproxy\conf directory, edit it and change the connector stanza from this:
<Connector
protocol=”org.apache.coyote.http11.Http11NioProtocol”
port=”8443″ maxThreads=”200″
scheme=”https” secure=”true” SSLEnabled=”true”
keystoreFile=”conf/stproxy.keystore” keystorePass=”samet1me”
clientAuth=”false” sslProtocol=”TLS”/>
to this
<Connector
protocol=”org.apache.coyote.http11.Http11NioProtocol”
port=”8443″ maxThreads=”200″
scheme=”https” secure=”true” SSLEnabled=”true”
keystoreFile=”YOURCERT.pfx” keystorePass=”YOURPASS” keystoretype=”PKCS12/”
clientAuth=”false” sslProtocol=”TLS”/>
Using certificate in pfx format makes the configuration much easier, as you see; there is no need to import anything, just modify the server.xml
HCL had a webinar on Sametime 11 and they talked about some of the most commonly faced issues. If you have not attended the webinar, here is the presentation, the last slides are referring to the issues.
In my previous post here I described how to set up a Jitsi server using the Domino directory as LDAP. That setup required all the users to authenticate before joining a room.
A customer of mine wanted a different thing, he wants to do video meetings with people external to his organization, that obviously are not listed in the Domino directory. I did some research and in the Jitsi forums I saw some other people have done something on that topic, so in the end I came up with a solution.
The idea is this, an user need to log in to create a new room while a guest has only to click on the room link to access it without any authentication.
NOTE: to make this work you should do a apt update and apt upgrade to receive the latest version of the packages used. At first for me this was not working but after the upgrade it did.
1) Go in /etc/prosody/conf.avail, you will see a file with your hostname and the extension.lua. In my case the server is named meeting.eld.it
Edit it and at the end of the file add this
VirtualHost "guest.meeting.eld.it"
authentication = "anonymous"
allow_empty_token = true
c2s_require_encryption = false
2) Then edit the file /etc/jitsi/meet/meeting.eld.it-config.js and add a domin for anonymous.
hosts: {
// XMPP domain.
domain: 'meeting.eld.it',
anonymousdomain: 'guest.meeting.eld.it',
3) Add this line in the /etc/jitsi/jicofo/sip-communicator.properties file
org.jitsi.jicofo.auth.URL=XMPP:meeting.eld.it
Now when a user access the server and create a room he is asked for credentials
All the other users can then join without being asked for credentials once the room is created.
If you set up two Jitsi servers, you can easily use both the solutions I described if you want to have internal users to authenticate and at the same time allow guest access. Use a server for internal meetings and the other for external ones. The Sametime web client can be configured with more than one external service provider. Unfortunately the Sametime connect client can not, you can define only one provider.
I have worked with my friend and fellow HCL Master Detlev Poettgen in setting up a solution to allow customers to use video-conferencing now, while we wait for Sametime Meetings to ship.
We have used Jitsi, the same technology used by Sametime meeting, and set up a raw integration. Is obviously not a fully integrated solution, but it works pretty well.
This is something useful for those customers who don’t want to use cloud services like Zoom or Webex or others, but prefer to have a completely on-premise solution, and I have more than one of this kind of customers.
To use this integration, change the preferences in the Sametime client and define an external meeting provider, using a room on the Jitsi server
The same for the web client
Installation and configuration of Jitsi
The first thing to do is to install Jitsi on Ubuntu server 18.04. You can find the instructions here
By default Jitsi does not use authentication, when you set up a Jitsi server, everyone who can access it can create a room or join an existing room.
There is the option to use LDAP for authentication, and I successfully set it up using Domino 11 as LDAP server.
I used the LDAP authentication for jitsi-meet via cyrus/saslauthd
At first, you need to install the following packages:
apt install sasl2-bin libsasl2-modules-ldap lua-cyrussasl
Then go in /etc/prosody/conf.avail, you will see a file with your hostname and the extension.lua, in my example the server is named meeting.eld.it
Edit it and change the authentication to cyrus and add the auth_cyrus to modules_enabled.
You also have to add the config options
cyrus_application_name = “xmpp”
allow_unencrypted_plain_auth = true`
as well.
The file should now be looking like this:
VirtualHost "meeting.eld.it"
-- enabled = false -- Remove this line to enable this host
authentication = "cyrus"
-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to "token"
--app_id="example_app_id"
--app_secret="example_app_secret"
-- Assign this host a certificate for TLS, otherwise it would use the one
-- set in the global section (if any).
-- Note that old-style SSL on port 5223 only supports one certificate, and will always
-- use the global one.
ssl = {
key = "/etc/prosody/certs/meeting.eld.it.key";
certificate = "/etc/prosody/certs/meeting.eld.it.crt";
}
cyrus_application_name = "xmpp"
allow_unencrypted_plain_auth = true
speakerstats_component = "speakerstats.meeting.eld.it"
conference_duration_component = "conferenceduration.meeting.eld.it"
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
"auth_cyrus";
"speakerstats";
"turncredentials";
"conference_duration";
}
c2s_require_encryption = false
Configure saslauthd
Create the file /etc/sasl/xmpp.conf. If the folder sasl do not yet exist, create it.
Paste the follwoing inside the xmpp.conf:
pwcheck_method: saslauthd
mech_list: PLAIN
Now create /etc/saslauthd.conf and add the following. Replace the IP with yours, as well as the search base and the Bind user/password!
ldap_servers: ldap://192.168.1.24:389 ldaps://192.168.1.24:636
ldap_search_base: o=eld
ldap_bind_dn: cn=Roberto Boccadoro,o=eld
ldap_bind_pw: password
ldap_filter: (mail=%u*)
ldap_version: 3
ldap_auth_method: bind
Important note on ldap filter:
At the first try I used ldap_filter: (mail=%u) but it didn’t work
Use ldap_filter: (mail=%u*) note the * direct after the %u, and tell your users to enter the portion before the @ sign of their mail address.
Now edit the /etc/default/saslauthd file:
and restart the service with service saslauthd restart. You also have to restart prosody now with service prosody restart.
Add prosody to the sasl group by executing the command usermod -aG sasl prosody.
Once you do this configuration, the users accessing your jitsi server will be asked for authentication before joining or creating a room.
Sametime 11 FP1 has shipped, so me and my fellow Master and friend Matteo Bisi started upgrading our test servers immediately.
We found a couple of thing you may want to be aware of in order to upgrade successfully.
Upgrading the Community server on Linux
Matteo did a upgrade of ST to FP1, but for whatever reson it failed. He had 23 file starting with st* in the data direcory instead of 40. So he did a uninstall of Domino and installed it again.
When trying the upgrade of Sametime he got this error
The problem is due to the fact that in the directory /var, there is a hidden file named .com.zerog.registry.xml. I looked into that file and found that it contained the information about Sametime 11 FP1
registry install_date="2020-03-10 11:26:39" version="1.1" last_modified="2020-04-09 09:41:28">
<product name="HCL Domino" id="0e1cb10d-1f39-11b2-8202-e8e16a17fbf8" upgrade_id="0e1cb10e-1f39-11b2-8202-e8e16a17fbf8" version="11.0.0.0" copyright="2018" info_url="www.hcl.com" support_url="www.hcl.com" location="/opt/hcl/domino/notes/11000000/linux" last_modified="2020-04-09 09:41:28"
.
.
.</product>
<product name="HCL Sametime Server 11.0 FP1" id="17cc219c-1f40-11b2-8e97-ef3209dd0f10" upgrade_id="a63c37b2-1f3f-11b2-af58-ef3209dd0f10" version="11.0.0.1" copyright="2019" info_url="" support_url="" location="" last_modified="2020-04-08 23:05:50">
.
.
.
I told Matteo to remove all the lines relative to Sametime in the file so that it looked like this
After that, the installation of FP1 was successful
Upgrading Sametime Proxy on Windows
When you unzip the Sametime_11.0_FP1_ProxyServer_Win64.zip file you will see that it contains a directory “sametimeproxy”.
Do not extract it where you already have your SametimeProxy overwriting the content. Extract it in another temporary directory.
From that directory launch install.bat; accept the license and in the following screen you will see this
The installer will recognize there is already a ST Proxy installed and ask you if you want to upgrade. If you select to do it, you will be asked where is it installed
Specify the directory where is your existing ST Proxy
This will upgrade your proxy server keeping the existing configuration.
I wrote a post explaining what to do to have user pictures show in the Sametime classic client and in the Sametime web client, here .
In a case, I found that the pictures did not show in the web client, so I opened a case with HCL Support. After debugging the problem, the great Trevor Tallackson found that my browser was trying to open a file that had a _tmp in the name
while on his server it was requesting the correct file with a .jpg extension
The solution is to delete the content of the temporary directory that the Sametime Proxy uses to store people pictures.c:/sametimeproxy/temp/userphotos
After doing that, I logged in again from the web client and the pictures were shown correctly.
If you want to enable photos in the Sametime client, there is documentation available, unfortunately it all refers to versions 9 or 10, where it was told to use the Sametime Console. Now in version 11 the Sametime Console does not exist, so how do you do that ? The Sametime Console wrote the settings selected in a series of XML configuration files, so the only way now to work is manually edit those files, see for example my previous post on enabling file transfer.
With the help (again) of the excellent Trevor Tallackson from HCL I was able to set up the pictures in Sametime, here is how to do it
First add the picture URL in the person document in the Domino directory
Now edit the file UserInfoConfig.xml located in the Domino program directory and add those lines<Detail FieldName="PhotoURL" Id="PhotoURL" Type="text/plain"/>
<Detail FieldName="PhotoURL" Id="ImagePath" Type="text/plain" />
in the section <Details>
Add these two Detail Ids to the <ParamsSets> section <Set SetId="0" params="MailAddress,Name,Title,Location,Telephone,PhotoURL,ImagePath,Company"/>
<Set SetId="1" params="MailAddress,Name,Title,Location,Telephone,PhotoURL,ImagePath,Company"/>
These are needed because in the UserInfoConfig.xml file on the Sametime Community server, the Standalone Connect client and Embedded require ImagePath string detail, Mobile and Web clients require the PhotoURL detail
Note: do not copy/paste from above. I had reports it does not work well. Just add PhotoURL and ImagePath to the params= line.
Now check the UserInfo servlet according to the instructions here https://www.ibm.com/support/knowledgecenter/SSKTXQ_10.0.0/admin/trouble/st_adm_buscard_troubleshoot_r.html
You should see something like this
For me it was not working initially, then Trevor wrote me this:
Looks like the stconfig.nsf “UserInfo” document is getting in the way here. Add the following to your UserInfoConfig.xml file between <UserInformation> and <Resources>
<ReadStConfigUpdates value= “false”/>
This tells the UserInfoServlet to only use the UserInfoConfig.xml configuration.
Restart the server and now you have pictures in Sametime client
I stumbled into a problem at one of my customers. In the client, the icon for file transfer was greyed out and the one for sending a screenshot was missing,
I opened a case with HCL and the suggestion was to enable the setting im.3000 in the file policies.user.xml.
to do so you have to edit the line <p:policy-attribute id=“im.3000” type=“boolean” current-value=“1” default-value=“1" master-attribute-link=“null” possibl .....
By default the current-value is 0, you have to set it to 1
I did that but the file transfer was not available the same.
After checking the file I found that there were 2 occurrences of im.3000, one for the im.default.policy and the other for the im.anonymous.policy, the problem is that this setting is written only in the section “imserver.policygroup.chat”. I copied the lines from that section and added them in the “imserver.policygroup.filetransfer” section.<p:policy-attribute id="im.3000" type="boolean" current-value="1" default-value="1" master-attribute-link="null" possible-value-labels="null" possible-values="null" label="im.3000.label" description="im.3000.desc" visible="true"/>
Restarted the server and now in the client I had this
Update
I checked with HCL, file transfer and screen capture are not allowed with Sametime limited use license. You should use the content of this blog post only to fix issues if you have a standard license and file transfer is not working. If you enable file transfer, you should upgrade your license to be compliant.
See here for information about what is allowed and what isn’t with the limited use license. https://hclpnpsupport.hcltech.com/csm?id=kb_article&sysparm_article=KB0068613
I installed a Sametime 11 server for a customer, everything was working, but the mobile clients could not access the server. Upon trying to login they saw this on their phones
I was not the only one with this problem, other 2 persons I know had the same issue with their installation.
I talked to my friend Andreas Ponte, from Belsoft who told me that they could use mobile clients, so we crosschecked our configurations.
and it turned out that my customer sametime.ini had this line
ST_BRANDING_INFO=entry while his had ST_BRANDING_INFO=standard
As soon as I changed the sametime.ini and restarted, the access from mobile devices was working.
I had installed Sametime withe the option “limited” because this is the license my customer has
So, the solution is simple but I have asked HCL to clarify. As far as I know since V10 the limited license allows the use of mobile clients, and I do not think this has changed in V11
UPDATE
I received a mail from HCL stating this:
For now, the workaround is to add the stanza to the stproxyconfig.xml and NOT change the ST_BRANDING_INFO in sametime.ini, since that setting controls other features/UI of the clients if you are only licensed for ENTRY.
<OverrideCSLUMobileRestriction>true</OverrideCSLUMobileRestriction>
inside the <configuration> element of stproxyconfig.xml.