Kolab Webadmin (WAP) 3.3

[Daniel Hoffend]

You should dive into ACLs of LDAP.

Maybe create a different Organization Unit (example: 
ou=Incative,ou=People) within the LDAP Structure and just move the 
people over. Set the ACLs that "normal" users or the users themself are 
not allowed to access this ou, but allow kolab-service user and your 
sysdmins to manage it. This way kolabd will not remove the imap folders 
(cause it still can see them) but the user thems elf can't access their 
own ldap entry and therefore can't login. If you want to hide those 
users from postfix as well (for example they should not receive emails 
when moved to incative) you should create a kolab-postfix ldap user with 
similar rights to kolab-service apart from not allowing him to access 
this inactive ou.

When you need the users just login as sysadmin, move the account from 
ou=Inactive,ou=People to ou=People and you can use them again. If you 
want to disable them change the ou back to ou=Inactive,ou=People.

--
greetings
Daniel


------ Originalnachricht ------
Von: "Stuart Naylor" <StuartIanNaylor at inbox.com>
An: "users at lists.kolab.org" <users at lists.kolab.org>
Gesendet: 22.08.2014 10:14:20
Betreff: Kolab Webadmin (WAP) 3.3

>
>
>Really like that WAP has some improvements and if I am reading things 
>correctly WAP is setup up so we can have delegated control over users.
>
>
>
>As a sysadmin with ever reducing budgets User admin because of time and 
>costs is a HR responsibility. So the current additions to WAP I really 
>welcome but please keep it really simple.
>
>
>
>I have a little pet project that is a community center run by 
>volenteers where I do the IT. Its a weird scenario as in conjunction 
>with Lancashire County Council we run courses and drop in sessions for 
>computer access.
>
>Its all abou tackling the problems of digital exclusion for various 
>sections of the community who are dissadvantaged in the digital online 
>world.
>
>
>
>I guess our work practises are just a little odd ball and they 
>dfeinately don't fit a software license that doesn't have a concurrent 
>user scheme.
>
>
>
>Courses generally run for 6 - 8 weeks 2 -4 hours on one day a week.
>
>Then we have just random drop in sessions where people can just get 
>free access.
>
>
>
>Even with the amazingly low priced software subscription the nature of 
>the amount of users we have and the administration of users is really 
>problematic.
>
>
>
>We might only have anywhere beween 15 - 30 users in the center at 
>anyone time but on the books we could have several hundred and more. 
>With the large majority being idle for most of the time.
>
>
>
>So if anybody is doing any dev work with WAP would it be possible to 
>disable / enable users without removing them from the directory.
>
>Having to delete and resubmit users is a huge administration task.
>
>
>
>It is also the same with account types as wow it would be handy to be 
>able to change the account type also.
>
>
>
>I really like WAP as many of the server systems I have used puts user 
>management into the system configuartion of the server. The delegated 
>user manager of WAP is just perfect as User management is a HR role and 
>not the remit of the sysadmin.
>
>
>
>I will have to have a go with the settings again but to be honest I 
>have been thinking of a little hack and hiding the settings section.
>
>Also I did try making a change on a field for auto generation and it 
>was a big mistake as apart from three fields all the kolab User fields 
>dissaperred on submit.
>
>
>
>
>
>
>
>
>
>--------------------------------------------------------------------------------
>Free Online Photosharing - Share your photos online with your friends 
>and family!
>Visit http://www.inbox.com/photosharing to find out more!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5714 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20140822/81029fc7/attachment-0001.bin>