LOTUSCONNECTIONS.org

I tried to figure out how I could map a group to
a role as used by the Lotus Connections apps.

It would be handy if I could create a group like blogadmins
which contains all the people which require admin
privileges on Blogs.

But unfortunately you can’t map groups to a role as used by
Connections, yeah you can but it won’t work.

http://www-10.lotus.com/ldd/lcforum.nsf/d6091795dfaa5b1185256a7a0048a2d0/c20e137e3b31e826852576fd00265771?OpenDocument

Because I can’t map a group to a role I need
to add every user individual.

I want this action to be scripted so I was looking how this could be
done. The trick was the separator which needs to be a “|”.

So check the script below.

appName = ‘Blogs’
lcsearchadmin=’LCdev admin’
blogadmins=’LCdev admin|Donald Duck|Dagobert Duck|Mickey Mouse’
lcadmin=’LCdev admin’

AdminApp.edit(appName, ‘[ -MapRolesToUsers [ ["person" no yes "" ""] ["everyone" yes no "" ""] ["reader" no yes "" ""] ["search-admin" no no "'+lcsearchadmin+'" "" ] [ "admin" no no "'+blogadmins+'" "" ]  ["widget-admin" no no "'+lcadmin+'" "" ] ] ]’)
print “done…. Configuring rights Blogs EAR”
AdminConfig.save()

Currently I am digging myself a way into the concept of SPNEGO in
combination with WebSphere servers. With SPNEGO you can create a SSO
config with your clients and WebSphere enabled websites.

The basis is that you have to use an Active Directory server ( W2K or higher ).
In order to make use of the SPNEGO function you have to logon to an AD domain.

When logged in to the AD domain you will receive a kerberos ticket and this is
what is nessecary to make this whole thing rolling.

Besides this requirement you will have to take the following things in consideration.

- AD domain ( W2K or higher )
- WebSphere Application Server 6.1 ( any OS )
- Security enabled for WAS
- A configured User Repository, stand-alone or federared both can be used.
- Type of User Repository can be any of the supported ones by WAS.
( NOTE:
There has to be a link between the login names in the
AD LDAP and the ones in the User Repository used by WAS.

Example: Login attribute in AD is samAccountName, the login attribute
of our WAS Domino User Repo is CN.

samAccountName = MEn
cn = Marco Ensing

Because Domino can use multple CN’s you will have to take care that the
name “MEn” needs to become a CN value in the domino LDAP.
)

For me of course enabling SSO with Lotus Connections is what I’am
looking for but this feature can be used with any Portal or
WebSphere Application server app. running on WAS version 6.1.

Found a two links that were very helpfull for me understanding the
whole concept of SNPEGO in combination with WebSphere.

Step-by-step guide enabling SPNEGO

SPNEGO TAI: Using single sign-on from Windows to WebSphere Application Server

Theory how-it-works

WebSphere with a side of SPNEGO

One handy tool that I found on the web is kerbtray.exe, I was
configuring SPNEGO for a customer running Portal 6.1 in a
Windows 2000 Domain.

When following the documentation mentioned above I
should use the encryption type of DES-MD5 for the keytab file.

Configuring everything to make use of this encryption type I
dug myself in trying serveral variations of the keytab file and
the non-stoppable reboots for the portal server.

But when I ran this tool, kerbtray.exe on one of the client
stations I saw that the encryption type used was RC4-HMAC,
one that only should be used in a Windows 2003 AD domain.

Had now clue why this was happening, but I created a new
keytab file with the encryption type RC4-HMAC thing
that then came above was that everything started working .

( Domain was formed by two Windows 2000 Domain Controlers
and a number of 10 Windows 2003 Domain Controllers.
The forest was Windows 2000 in mixed mode )

Think I have to find a explanation for this behaviour from
the Windows administrators corner.

Windows 2000 Resource Kit Tool: Kerbtray.exe

In our situation we have one was profile with 6 servers instances
on it, one server instance for every part of Lotus Connections.

Whenever we want to use a checkOut config task for server2
( or server3 till server6 ) we have to do this on the SOAP port of server1.

example:
./wsadmin.sh -lang jython -user wasadmin -password ********** -port 8880
execfile(“communitiesAdmin.py”)
CommunitiesConfigService.checkOutConfig(‘/tmp’, ‘con10Node01Cell’)

For changes on a part of Lotus Connections that does not require
you to use the checkOutConfig task you can do this directly at
the SOAP port of that server instance.

example:
./wsadmin.sh -lang jython -user wasadmin -password ********** -port 8883
execfile(“communitiesAdmin.py”)
CommunitiesService.purgeIndex()
CommunitiesService.startIndexing()

At my company e-office, we were working on a customization in
Lotus Connections for one of our customers.

Because every change regarding the lay-out ( editing a *.HTML,*.CSS,*.JS file )
requires a restart of the specific EAR ( Activities , Blogs, etc ) I made
a script in WSadmin python so we could simplify this process.

Now we can restart an EAR file with a single command line instead
of clicking yourself senseless through the WASadmin web interface .

FILE restart_activities.py

appName=’Activities’
server=’server1′

cell=AdminConfig.list(‘Cell’)
cellname=AdminConfig.showAttribute(cell,’name’)
nodes=AdminConfig.list(‘Node’,cell)
nodename=AdminConfig.showAttribute(nodes,’name’)
appManager=AdminControl.queryNames(‘type=ApplicationManager,cell=’+cellname+’,node=’+nodename+’,process=’+server+’,*’)

AdminControl.invoke(appManager, ’stopApplication’,appName)
AdminControl.invoke(appManager, ’startApplication’,appName)

!FILE

wsadmin.bat -lang jython -user wasadmin -password ***** -port 8880 -f .\wsadmin_scripts\restart_activities.py

Create a *.py for every part of Lotus Connections.

We configured our Lotus Connections setup to use our Domino LDAP
as the user repository.
In this Domino LDAP we have a primair and secondary addressbook.

When configuring profiles to use our Domino LDAP we discovered that
profiles wouldn’t read any entries that were in the secondary address book.

But after some experimenting with the settings in the file profiles_tdi.properties
we found out that when we leave the parameter source_ldap_search_base
empty we were able to retrieve the users from the secondary address book.

Strange issue but for now we can work with it.