Thanks to ZM's eagle eye that caught the culprit, the 'User' parameter
should be 'Username' in [SQLPasswordAuth] & [SQLAliasAuth] sections.
Regards,
Ap.Muthu
>If we want to allow Aliases based on AliasAuth(RasSrv::RRQAuth) or
> SQLAliasAuth,
> the authrule conditions coupled with confirm/reject allow/deny of the
> default parameters is very confusing.
>
> After reasonable experimentation with the gatekeeper.ini options, the
> following seems to work:-
>
> [Gatekeeper::Auth]
> SimplePasswordAuth=optional;RRQ
> SQLPasswordAuth=optional;RRQ
> AliasAuth=optional;RRQ,ARQ
> SQLAliasAuth=optional;RRQ,ARQ
> default=reject
>
> [RasSrv::RRQAuth]
> MYEP5=allow
>
> [SQLPasswordAuth]
> Driver=MySQL
> Host=localhost
> Database=gkcontrol
> User=gnugk
> Password=secret
> CacheTimeout=300
> Query=SELECT h235password FROM users WHERE alias = '%1' AND IS active
>
> [SQLAliasAuth]
> Driver=MySQL
> Host=localhost
> Database=gkcontrol
> User=gnugk
> Password=secret
> CacheTimeout=300
> Query=SELECT CONCAT('sigip:',host,':',port) as authrule FROM users WHERE
alias
> = '%1' AND GatekeeperId = '%2' AND active
>
> Also an ODBC SystemDSN and MySQL User (ODBC)
> will need to be created for the database used in Win32
> till the GK code is updated.
>
> Kindly note that the entry:-
> default=deny
> or
> default=allow
> are conspicuously missing from the last 3 Auth sections above.
>
> This is what caused so much misery in finding out what works.
>
> The manual should be updated to explain [Gatekeeper::Auth] - "optional":-
>
> <item><tt/optional/ - If the rule cannot determine the request, it is
passed
> to next rule.
> If a default entry of allow / deny or confirm / reject is available,
> it too will be used in determining the request. So if a default entry is
> given, then it will certainly yield a result.
> But if it is able to determine the request and if the default=deny entry
is
> present, it will deny the request and prevent any further processing.
> If the default entry is missing and if it is unable to determine the
request,
> then it is passed on to the next rule.
> If the default entry=allow is present and it is unable to determine the
> request, then also it is passed onto the the next rule.
>
> I hope this helps in understanding the effect of cumulative rule sets.
>
> If an alias has it's ennty as "allow" in the ini file's [RasSrv::RRQAuth]
and
> also has it's IP and port details in the SQLAliasAuth database and each is
in
> a different admin's control, and only such endpoints that satisfy both
must be
> allowed, then the default=deny parameter would be useful.
>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/
