Re: two ldap modules (Re: LDAP Auth: Require user to be in specified LDAP-group)

2012-12-13 Thread Tomasz Sterna
Dnia 2012-12-12, śro o godzinie 09:40 -0700, Justin T Pryzby pisze:
 Is there any reason to maintain both?

Not really. The lack of knowledge of LDAP prevented me from merging
these, but I didn't want to reject this usefull user submition, so I
merged it as-is.

If anyone is willing to make effort to merge these modules, without
loosing any functionality (especially option to use both methods of
checking user authority - binding and reading password) I will gladly
accept patches.

   What does full mean in ldapfull? 

Nothing that I know of. Just a distinct name from the other ldap storage
implementation.





Re: two ldap modules (Re: LDAP Auth: Require user to be in specified LDAP-group)

2012-12-13 Thread Guido Winkelmann
Am Mittwoch, 12. Dezember 2012, 09:40:49 schrieb Justin T Pryzby:
 I compared the two ldap modules here:
 http://www.mail-archive.com/jabberd2@lists.xiaoka.com/msg01381.html
 (Was it really three years ago??)
 
 Is there any reason to maintain both?  What does full mean in
 ldapfull?

At a guess, this might be for forward compatibility for configuration files. 
ldap and ldapfull are not configured exactly the same way, so if you merge 
them (and maybe make ldapfull a synonym for ldap), someone's configuration 
will inevitably break, especially if they install the update without 
thoroughly reading the changelog.

Two examples off the top of my head:

- ldapfull specifies the LDAP server to use as a free form URI, which it just 
passes on unchanged to the underlying API (which is IMHO the way it should be 
done), while ldap takes host and port as two separate directives
- ldap supports custom filters, ldapfull does not

Guido




Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-13 Thread Guido Winkelmann
Ah, nobody use that yet, please. I just realized I forgot some ldap_memfree() 
calls in _ldapfull_check_password(), so this will probably leak memory...

Am Donnerstag, 13. Dezember 2012, 14:47:12 schrieb Guido Winkelmann:
 The same patch for git master.




Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-13 Thread Guido Winkelmann
The first patch had a memory leak.

Am Mittwoch, 12. Dezember 2012, 17:07:34 schrieb Guido Winkelmann:
 This patch appears to work. Note, I have only done superficial testing
 (checked that I can log in as a user who is in the specified group and that
 I can not log in as one that is not in this group). I have not tested this
 against AD, only OpenLDAP.
 
 This patch applies to 2.2.17, but not to git-master.
 
   Guidodiff -rup jabberd-2.2.17-orig/etc/c2s.xml.dist.in jabberd-2.2.17/etc/c2s.xml.dist.in
--- jabberd-2.2.17-orig/etc/c2s.xml.dist.in	2012-05-22 22:27:51.0 +0200
+++ jabberd-2.2.17/etc/c2s.xml.dist.in	2012-12-12 16:39:54.490003311 +0100
@@ -546,6 +546,15 @@
   !--
   validattrvalid/validattr
   --
+
+  !-- Group that users must be members of
+   If this is set, only user that are members of the specified LDAP
+   group can log in. The group must be specified with its full 
+   distinguished name --
+  !--
+  group_dncn=jabberdusers,ou=servicegroups,dc=example,dc=com/group_dn
+  --
+
   fulluid/
   !-- If pwscheme is not defined, then passwords are stored in clear
text and digest authentication may be done.
diff -rup jabberd-2.2.17-orig/storage/authreg_ldapfull.c jabberd-2.2.17/storage/authreg_ldapfull.c
--- jabberd-2.2.17-orig/storage/authreg_ldapfull.c	2012-02-19 14:23:09.0 +0100
+++ jabberd-2.2.17/storage/authreg_ldapfull.c	2012-12-13 16:30:13.690004078 +0100
@@ -68,6 +68,7 @@ typedef struct moddata_st
 char *objectclass;
 char *uidattr;
 char *validattr;
+char *group_dn;
 char *pwattr;
 char *pwscheme;
 
@@ -583,6 +584,50 @@ retry:
 return dn;
 }
 
+/** Is this user part of the given LDAP group? */
+static int _ldapfull_user_in_group(moddata_t data, char *user_dn, char *group_dn)
+{
+LDAPMessage *result, *entry;
+int tried = 0;
+char filter[1024];
+ 
+log_debug(ZONE, checking whether user with dn %s is in group %s, user_dn, group_dn);
+
+memset(filter, 0, 1024);
+snprintf(filter, 1024, (member=%s), user_dn); // TODO Check if snprintf result was truncated
+
+retry:
+if(ldap_search_s(data-ld, group_dn, LDAP_SCOPE_BASE, filter, NULL, 0, result))
+{
+if( tried++  LDAPFULL_SEARCH_MAX_RETRIES ) {
+log_debug(ZONE, ldap: group search fail, will retry; %s: %s, filter, ldap_err2string(_ldapfull_get_lderrno(data-ld)));
+_ldapfull_unbind(data);
+if( _ldapfull_connect_bind(data) == 0 ) {
+goto retry;
+} else {
+return 0;
+}
+}
+log_write(data-ar-c2s-log, LOG_ERR, ldap: group search %s failed: %s, filter, ldap_err2string(_ldapfull_get_lderrno(data-ld)));
+_ldapfull_unbind(data);
+return 0;
+}
+
+entry = ldap_first_entry(data-ld, result);
+if(entry == NULL)
+{
+ldap_msgfree(result);
+
+return 0;
+}
+else 
+{
+ldap_msgfree(result);
+
+return 1;
+}
+}
+
 /** do we have this user? */
 static int _ldapfull_find_user_dn(moddata_t data, char *username, char *realm, char **dn)
 {
@@ -601,6 +646,11 @@ static int _ldapfull_user_exists(authreg
 {
 char *dn;
 if (_ldapfull_find_user_dn((moddata_t) ar-private, username, realm, dn)) {
+if(((moddata_t) ar-private)-group_dn != NULL
+ !_ldapfull_user_in_group((moddata_t) ar-private, dn, ((moddata_t) ar-private)-group_dn)) {
+ldap_memfree(dn);
+return 0;
+}
 ldap_memfree(dn);
 return 1;
 }
@@ -748,22 +798,54 @@ static int _ldapfull_check_password(auth
 {
 moddata_t data = (moddata_t) ar-private;
 char buf[LDAPFULL_PASSBUF_MAX];
+char *dn = NULL;
 
 log_debug(ZONE, checking password for %s, username);
 
 if(password[0] == '\0')
 return 1;
 
+if(data-group_dn != NULL) {
+if (!_ldapfull_find_user_dn(data, username, realm, dn))
+return 1;
+}
 /* The bind scheme doesn't need the password read first, so short circuit
the whole passhash scheme */
-if (!strcmp(data-pwscheme, bind))
-return _ldapfull_check_password_bind(ar, username, realm, password);
+if (!strcmp(data-pwscheme, bind)) {
+if(_ldapfull_check_password_bind(ar, username, realm, password) == 0) {
+if(data-group_dn != NULL  !_ldapfull_user_in_group(data, dn, data-group_dn)) {
+ldap_memfree(dn);
+return 1;
+}
+else {
+ldap_memfree(dn);
+return 0;
+}
+}
+}
 
 if( _ldapfull_get_password(ar,username,realm,buf) != 0  ) {
+if(dn != NULL)
+ldap_memfree(dn);
 return 1;
 }
 
-return ! _ldapfull_check_passhash(data,buf,password);
+if(_ldapfull_check_passhash(data,buf,password)){
+if(data-group_dn != NULL  

Re: Unable to connect to server, probably database related

2012-12-13 Thread Dylan

On 12/13/2012 04:03 AM, Tomasz Sterna wrote:
 Dnia 2012-12-12, śro o godzinie 13:29 -0500, Dylan pisze:
 Okay, so I'm trying to set up a jabber server on my laptop. I'm
 running on Fedora 17 x86_64 and [...] Any suggestions?
 Check server logs first. There may be some helpful error messages there.
 I see you are logging to syslog, so look at jabberd/ lines
 in /var/log/messages.

 Try running c2s and/or sm with -D switch to enable debug. (If Fedora's
 jabberd is built with debugging support.)


 P.S. Fedora's 2.2.14 is old. I strongly suggest upgrading.




I downloaded 2.2.16 and compiled it from source. It works now, though I
still have no clue why it didn't before. Thank you for the assistance.