Control access to mailing lists in SWA?

[CharlieBrooks]

My question is:

Where can I find a complete list of the variables available to me in swa.properties?

I have a mature OpenLDAP infrastructure which contains organizational units called "mailing lists" and "restricted mailing lists".

The "mailing lists" OU contains mailing lists that correspond to posix groups and functional business groupings such as project team members and the like. They are set up to be useable by SWA as objectClass groupOfNames with Member attributes, no problem there.

The "restricted mailing lists" OU contains mailing lists that are not intended to be exposed to all users of SWA - they are sensitive in nature, things like client emergency contact lists to be used only by corporate officers during a catastrophe, for example.

At first glance, this is easy enough to configure in swa.properties. Unfortunately, the %u variable does not translate to the authentication ID of the user, instead it translates to their email address (which is the bind DN for the scalix LDAP engine on localhost, so it actually is the authentication ID in that particular context). In our LDAP tree, the email addresses are userID@domain.org, and I want to bind to our OpenLDAP server with userID so that my existing access controls will determine which mailing lists each user can see and/or use.

The good part is that SWA does properly supply the userPassword we want it to use. It just uses a different bind DN than I expected (we tested this by turning up the logging on slapd and running tcpdump on the port.)

Thanks,
--Charlie

[LeslieW]

Hey Charlie,

The example bindDN in the comments of swa.properties is cn:
swa.ldap.<n>.bindDN=cn=Administrator,o=Scalix

The default bindDN for the SYSTEM directory is the mail address:
swa.ldap.1.bindDN=mail=%u

Scalix doesn't return authid as an LDAP attribute.

$ omshowu -n ward
Authentication ID: lward
<...>

I have my attributes pretty well populated at the moment. As you can see, none of them equate to the authid:
$ omldapsearch "cn=Leslie Ward"
cn=Leslie Ward, o=Scalix
cn=Leslie Ward
l=City
st=NJ
c=US
street=Street
objectClass=top
objectClass=person
objectClass=organizationalPerson
objectClass=mhsUser
objectClass=scalixPerson
surname=Ward
title=Title
description=notes1 notes2 notes3
postalCode=26178
physicalDeliveryOfficeName=Office
telephoneNumber=work phone
facsimileTelephoneNumber=fax
givenName=Leslie
mhsORAddresses=S=Ward/G=Leslie/OU1=sxlab/CN=Leslie Ward
omInternetAddr="Leslie Ward" <Leslie.Ward@mydomain.net>
omInternetAddr="Leslie Ward" <leslie@mydomain.net>
omInternetAddr="Leslie Ward" <lward@mydomain.net>
mail=Leslie.Ward@mydomain.net
mail=leslie@mydomain.net
mail=lward@mydomain.net
rfc822Mailbox=Leslie.Ward@mydomain.net
rfc822Mailbox=leslie@mydomain.net
rfc822Mailbox=lward@mydomain.net
homeTelephoneNumber=home phone
mobileTelephoneNumber=mobile
pagerTelephoneNumber=pager
omHomePhone2=home phone2
omAddress=Leslie Ward /sxlab/CN=Leslie Ward
omMailnode=sxlab
omCn=Leslie Ward
omEmplOrg=Company
omEmplDept=Department
omPhone2=work phone 2
omGlobalUniqueId=1b2000001493ed94-121.0.861.291
omLocalUniqueId=705
omUlClass=Full

The attributes we use are defined in /opt/scalix/template/release.sys/slapd.schema; could you use one of those attributes for binding to your LDAP server?

[CharlieBrooks]

Hi Leslie! Fancy meeting you here!

Hmmm, are you saying there's a syntax available in swa.properties that will let me access anything in the scalix LDAP store, and therefore I can re-purpose some unused attribute found in /opt/scalix/template/release.sys/slapd.schema to hold my users' bind DNs and pull that into scalix via omldapsync? That's clever! The only problem would be if I chose some attribute that ended up getting used for something else in the future... I guess I better go look at the attribute definitions and see what jumps out at me. Maybe "teletexTerminalIdentifier" - that's probably not going to be needed in the future.

These are the variables I know to be available in swa.properties:

%h = scalix host holding this users' IMAP store
%s = user input to checknames or addressbook search
%u = this user's fully qualified email address

How would I reference other attributes?

(As usual, I'd love to see the source code that actually reads swa.properties, and of course I'd sign whatever nondisclosure/noncompete Xandros requires.)

[LeslieW]

You and your source code desires

Hmmm, are you saying there's a syntax available in swa.properties that will let me access anything in the scalix LDAP store, and therefore I can re-purpose some unused attribute found in /opt/scalix/template/release.sys/slapd.schema to hold my users' bind DNs and pull that into scalix via omldapsync? That's clever!

I've not ever tested this but what you'd want to look at is the section where the different directories are defined (swa.ldap.1, swa.ldap.2, and so on). swa.ldap.1 is the SYSTEM directory, or the global address book; this is the directory to which omldapsync imports data. swa.ldap.2 is the Personal Contacts list. You can also define other directories.

The bit used for authentication is:
# LDAP Bind DN (optional)
# Note: Use %u to represent the user's name as identified by his eMail address
# swa.ldap.<n>.bindDN=cn=Administrator,o=Scalix

In the example above they are using a regular "cn=Administrator,o=Scalix" DN, but if you wanted to use the email address for the DN you'd put
swa.ldap.<n>.bindDN=%u

So, for your purposes, you'd probably want something like
swa.ldap.<n>.bindDN=teletexTerminalIdentifier

I'm basing this on the way users bind to their Personal Contacts:
swa.ldap.2.bindDN=rfc822mailbox=%u

In other words, when you open your "Contacts" folder, SWA does an LDAP search, binding with your email address. That way you get only your own Personal Contacts presented to you.

Seems to me you could identify any attribute available to Scalix. This is conjecture, because I've not tried it myself, but it's the first thing I'd try. I must say, your questions always ensure I'll learn to think of this product in new and creative ways.

(As usual, I'd love to see the source code that actually reads swa.properties, and of course I'd sign whatever nondisclosure/noncompete Xandros requires.)

Uh-huh.

[CharlieBrooks]

But working without the source makes it really hard. Check out how tedious the process is, shooting in the dark...

I can't figure out how to access arbitrary values from the scalix LDAP store or an external LDAP store to use in swa.properties. The only documented values provided by scalix are %s, %h and %u which are great but I need authentication-ID. So, first I tried the obvious:

I modified swa.properties to add this (which doesn't work, of course)

swa.ldap.3.type=public_list
swa.ldap.3.displayName.resourceLabel=Mailing Lists
swa.ldap.3.displayName.resourceID=addressbooksearch_title_public_list
swa.ldap.3.server=127.0.0.1
swa.ldap.3.port=9009
swa.ldap.3.bindDN=uid=%u,ou=People,dc=mycompany,dc=org <-- looky here!
swa.ldap.3.baseDN=ou=mailLists,dc=mycompany,dc=org
swa.ldap.3.authType=simple
swa.ldap.3.filter=(&(objectclass=scalixGroupClass)(|(cn=*%s*)(mail=%s*)(displayName=*%s*)(scalixEmailAddress=%s*)))
swa.ldap.3.addressSearchLimit=250
swa.ldap.3.checkNames.nameAttribute=scalixEmailAddress

swa.ldap.3.search.1.type=name
swa.ldap.3.search.1.header=true
swa.ldap.3.search.1.name.resourceID=addressbooksearch_label_name
swa.ldap.3.search.1.name.resourceLabel=Name
swa.ldap.3.search.1.dirAttribute=displayName

swa.ldap.3.search.2.type=email
swa.ldap.3.search.2.name.resourceID=addressbooksearch_label_email
swa.ldap.3.search.2.name.resourceLabel=Email Address
swa.ldap.3.search.2.header=true
swa.ldap.3.search.2.dirAttribute=scalixEmailAddress

swa.ldap.3.search.3.type=
swa.ldap.3.search.3.header=true
swa.ldap.3.search.3.name.resourceID=addressbooksearch_label_desc
swa.ldap.3.search.3.name.resourceLabel=Description
swa.ldap.3.search.3.dirAttribute=description

I schedule a scalix-tomcat restart so this can be tested and come in to work at 4 AM (so we can back it out quick if it breaks SWA for hundreds of users). Scalix-tomcat restart cannot be done during normal hours or without scheduling.

Now, with this configuration in place, I see an extra choice in SWA for address lookups called "Mailing lists". That's great, it means I got something right. Now, we fire up tcpdump on the loopback address and capture everything on port 9009 which is where the LDAP source is.

Analyzing the packet traffic from tcpdump, we see that SWA is using the correct password for whichever user is logged into SWA. This is absolutely great! Unfortunately, as expected, the bind DN is no good since it has this:

uid=user@mycompany.org,ou=People,dc=mycompany,dc=org

instead of this:

uid=user,ou=People,dc=mycompany,dc=org

OK, so I google and post in the forum etc. and nobody knows how to do this. I have no source code, so you and I dream something up; "Hey, Leslie's got an idea going on there - what if the resourceID field in swa.properties provides a name I can reference in other places? Or maybe resourceLabel?"

OK, so now I can start trying to use resourceIDs and resourceLabels, with and without percent signs, and perhaps it will work... of course, it means I have to work weekends and/or repeatedly come in at 4AM until we find a solution by trial and error. In two or three weeks I will exhaust all the possibilities of syntax and I can start over again with some new idea.

We're flailing around in the dark...

[CharlieBrooks]

OK, so I got tired of banging my head against a wall, and started working on it a different way, and found things I think are bugs.


Background:

I already have a perl program that maintains mailing lists based on POSIX group membership; it queries the corporate directory via LDAP and builds arrays of email users, POSIX groups, and mailing lists. If there is a match between the name of a POSIX group and a mailing list, the mailing list is revised (again via LDAP) as necessary to make sure it contains only the names of the email users who are members of the matching POSIX group. If there is no name match, the mailing list is simply checked to make sure that any local addresses it contains are valid, deleting any that are not. This process lets sysadmins create mailing lists corresponding to POSIX groups that will be automagically maintained, without making every single POSIX group into a mailing list. The lists are available to all our LDAP-aware systems, not just scalix, and are extremely useful.

I added a call-out to omldapsync at the end of this program. I can modify the filters in swa.properties to provide separate listings of users and lists in SWA. My intention was to write another perl program to run on the scalix backend host that will pull the mailing list owners from the corporate directory with LDAP and resolve access controls using omshowaci, omaddaci, omdelaci, etc.

Other necessary background:

We do not let omldapsync delete users from our scalix system. Scalix omldapsync does not do mail archival on deletion, which is a requirement for us. Our existing user account termination process does a lot of stuff, including manipulation of the telephone PBX, voice mail system, and many other complex multi-user systems as well as modifying the corporate directory. It was simple to add scalix sxmboxexp and omdelu to the existing process, so that the state of the user mailbox at account termination is archived.


This is where the bugs begin:

Probable bug #1) I have found that omldapsync does not remove entries from mailing lists in scalix when they are removed from the source directory. I do not know if this is because we don't let omldapsync delete user accounts, or if it's a more global bug, and would be interested in the experiences of others.

Possible bug #2) I have found that omldapsync can put objects into scalix that can't be removed with other tools. Specifically it can import the single quote (and possibly other metacharacters) which prevents the use of command-line tools such as omdelpdln. Hmmm... I wonder if the GUI can do it? I will experiment with SAC right now... OK, since the group is sourced from omldapsync it cannot be manipulated with SAC either. I have an account named "Tony's test account" (thanks, Tony) which I can't remove from a PDL in scalix even though I have already removed it from mailing list at the LDAP source.

I put bug #1 as "probable" because it might not be a code bug but a rather a design oversight related to omldapsync's deletion restriction. Removal of an entry from a PDL might have been mistakenly classified as equivalent to deleting a mail store.

I put bug #2 as "possible" because it's entirely possible that I'm just too stupid to figure out a valid syntax that will escape the metacharacter for omdelpdln.


This post is mostly just to share info with the scalix/SWA community, but any advice or help is gratefully accepted....

[Valerion]

You will have to show us how you delete the PDL entry. Some characters need to be escaped on the shell, because it's expanded, and some are internally replaced by Scalix with other characters. E.g. my surname is "van Heerden". In a om*u command I need to replace it with "van_Heerden", but not in a om*ent command. There a space is acceptable.

[CharlieBrooks]

...show us how you delete the PDL entry. Some characters need to be escaped on the shell, because it's expanded, and some are internally replaced by Scalix with other characters. E.g. my surname is "van Heerden". In a om*u command I need to replace it with "van_Heerden", but not in a om*ent command. There a space is acceptable.

Thank you, Valerion!

Here is how the entry is returned from omshowpdln:

Tony's account /hscalix1/CN=Tony's test account

Here is what I've tried so far, with the corresponding error messages:

>omdelpdln -l IS -n "Tony\'s account /hscalix1/CN=Tony\'s test account"
omdelpdln : [OM 18025] The requested name is not in the PDL

>omdelpdln -l IS -n 'Tony\'s account /hscalix1/CN=Tony\'s test account'
omdelpdln : [OM 18025] The requested name is not in the PDL

>omdelpdln -l IS -n "Tony's account /hscalix1/CN=Tony's test account"
omdelpdln : [OM 18025] The requested name is not in the PDL

>omdelpdln -l IS -n "Tony's account"
omdelpdln : [OM 18025] The requested name is not in the PDL

>omdelpdln -l IS -n "Tony's test account"
omdelpdln : [OM 8012] The name contains more than one surname, or initials/generation are missing a '.'

>omdelpdln -l IS -n "Tony's_test_account"
omdelpdln : [OM 18025] The requested name is not in the PDL

>omdelpdln -l IS -n "Tony's_account"
omdelpdln : [OM 18025] The requested name is not in the PDL

omdelpdln -l IS -n "Tony\'s_account"
omdelpdln : [OM 18025] The requested name is not in the PDL

I have also tried using the -f switch and putting all these forms into a file, with no luck.

Thank you for the suggestion, it didn't help this time but it is good to know about underscore substitution.

[Valerion]

Do a omshowpldn, as well as a omshowu on the user in question.

[CharlieBrooks]

Do a omshowpldn, as well as a omshowu on the user in question.

[root@hscalix1 ~]# omshowpdln -l IS -x
X Tony's account /hscalix1/CN=Tony's test account
X Charles Brooks /hscalix1/CN=Charles X. Brooks
(15 other entries redacted)

[root@hscalix1 ~]# omshowpdln -l IS -n "Tony's account"
Tony's account /hscalix1/CN=Tony's test account

[root@hscalix1 ~]# omshowu -n "Tony's account"
Authentication ID: ttest
Globally Unique ID: uid=ttest,ou=People,dc=mycompany,dc=com
User Name : Tony's account /CN=Tony's test account
MailNode : hscalix1
Internet Address : ttest@mycompany.com=ttest@hscalix1.mycompany.com
System Login : 15051
Password : unset
Admin Capabilities : NO
Mailbox Admin Capabilities : NO
Language : C
Mail Account: Unlocked
Last Signon : 05.31.09 21:13:32
Receipt of mail : ENABLED
Service level : 0
Excluded from Tidying : NO
Recovery Folder visible : NO
User Class : Full
SIS URL : sxidx://hscalix1.mycompany.com/01b65000 ... 081.351.01

[root@hscalix1 ~]# omsearch -e s=account/g="Tony's" -x
Tony's account /hscalix1/CN=Tony's test account

[CharlieBrooks]

OK, remember when I said it was possible that I'm too stupid to figure out the right syntax for the PDL member deletion? Apparently that was the case.

In most of the PDL manipulation commands you just use the short name of the PDL.

[root@hscalix1 ~]# omshowpdln -l IS
Tony's account /hscalix1/CN=Tony's test account
Charles Brooks /hscalix1/CN=Charles X. Brooks

BUT, in the omdelpdln command, you MUST use the full omAddress name of the list.

[root@hscalix1 ~]# omdelpdln -l IS -n "Tony's account"
omdelpdln : [OM 18025] The requested name is not in the PDL

[root@hscalix1 ~]# omdelpdln -l "IS /hscalix1/CN=IS group mailing list" -n "Tony's account"
Names successfully deleted from public distribution list

Please accept my apologies for wasting your time with my incompetence, Valerion. I really appreciate your willingness to help!

The other problems I've referenced in this thread still exist, of course.