Fail to log in
Gilles Badouet
badouetg at uni.coventry.ac.uk
Wed Jul 31 18:21:00 EDT 2013
Hi Daniel,
I am using OpenDJ 2.7 (an OpenDS forks) and:
>Your login.config has typos:
> * principal should be bindDn
bindDn does not work (unable to connect to ldap or retrieve ladap connection in idp-process.log)
>* ServiceCredential should be bindCredential
Same thing, the use of bindCredential leads to the above error and therefore not even connection to ldap server at least.
I note that I have used both principal and ServiceCredential few days ago within another testing environement (but still with openDJ 2.7) and it worked properly. The use of bindDn and bindCredential was not working. By the way, what is the difference between bindDn and ServiceCredential ; principal and bindCredential ? and when to use one or other?
>* LdapUrl should be ldapUrl
I will check this in the our uni lab tomorrow.
Thanks
Kind regards
Gilles Rubens Badouet
Student ID: 3940347
Faculty of Engineering and Computing
MSc Network Computing Course
Mobile: 07424486426
________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of users-request at shibboleth.net <users-request at shibboleth.net>
Sent: 31 July 2013 22:32
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 146
Send users mailing list submissions to
users at shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at shibboleth.net
You can reach the person managing the list at
users-owner at shibboleth.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Configuring SP to limit each user to one concurrent session
(Klumpenaar, Michael (US - Newton))
2. Re: Fail to log in (Daniel Fisher)
3. Re: Configuring SP to limit each user to one concurrent
session (Cantor, Scott)
4. Re: login.config to use private-CA-issued certificate
(Daniel Fisher)
----------------------------------------------------------------------
Message: 1
Date: Wed, 31 Jul 2013 21:02:45 +0000
From: "Klumpenaar, Michael (US - Newton)" <mklumpenaar at deloitte.com>
Subject: Configuring SP to limit each user to one concurrent session
To: "users at shibboleth.net" <users at shibboleth.net>
Message-ID:
<3B7BB851E1C3B348B069A795E50BD1CA1373E3FA at USNDC1439.us.deloitte.com>
Content-Type: text/plain; charset="utf-8"
I have been unable to find any way to configure the SP to limit a user to a single concurrent session, which is a requirement in our system. We are also exploring ways of enforcing this constraint at the IdP, but believe that an SP solution will be easier to implement and maintain.
The sessionHook attribute looks like it could potentially be used to block additional sessions for a user, but I?m not sure if there is a way to determine if other sessions already exist.
Any help or insight into this issue is much appreciated.
Thanks,
--Mike
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.
v.E.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130731/ea7c91b5/attachment-0001.html
------------------------------
Message: 2
Date: Wed, 31 Jul 2013 17:23:14 -0400
From: Daniel Fisher <dfisher at vt.edu>
Subject: Re: Fail to log in
To: Shib Users <users at shibboleth.net>
Message-ID:
<CAFC6YwSbqXZnX0dzWssPqUCZ1QDoLp3py4wCFu67y92qpJMQ5A at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Jul 31, 2013 at 12:06 PM, Gilles Badouet <
badouetg at uni.coventry.ac.uk> wrote:
> > 15:09:48.863 - DEBUG
> >
> [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:194]
> > - User authentication for xxx failed
>
> >The next line in your log should be a stack trace which hopefully will
> >provide more information.
>
> Hi Tom,
>
> Below is a more complete log:
>
> 17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:83] -
> Created authenticator:
> edu.vt.middleware.ldap.auth.AuthenticatorConfig at 5867073::env={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> principal=cn=Directory Manager, LdapUrl=ldap://lonfp2.ans.local:389,
> ServiceCredential=shibans}
>
Your login.config has typos:
* principal should be bindDn
* LdapUrl should be ldapUrl
* ServiceCredential should be bindCredential
--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130731/7ad884cb/attachment-0001.html
------------------------------
Message: 3
Date: Wed, 31 Jul 2013 21:25:57 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: Configuring SP to limit each user to one concurrent
session
To: Shib Users <users at shibboleth.net>
Message-ID:
<BA63CEAE152A7742B854C678D9491383AD13790C at CIO-KRC-D1MBX01.osuad.osu.edu>
Content-Type: text/plain; charset="iso-8859-1"
On 7/31/13 5:02 PM, "Klumpenaar, Michael (US - Newton)"
<mklumpenaar at deloitte.com> wrote:
> We are also exploring ways of enforcing this constraint at the IdP, but
>believe that an SP solution will be easier to implement and maintain.
I don't think it's easy to do anywhere. Of the two, extending the IdP is
much easier for most people because Java is more understood than C++. But
I can't think of any way to do it at the IdP.
>
>
>The sessionHook attribute looks like it could potentially be used to
>block additional sessions for a user, but I?m not sure if there is a way
>to determine if other sessions already exist.
There isn't. The only way architecturally to do this today in the SP is
with a lot of custom plugin code in the session cache area. That's not a
path worth taking.
The most direct route is to add application code to do this, and using the
sessionHook might be part of a mechanism, but a fundamental problem is
that the web does not support logout in any meaningful way, and so you
have no way to avoid people getting locked out by sessions that are old.
You can expire them quickly, of course, that's about it.
-- Scott
------------------------------
Message: 4
Date: Wed, 31 Jul 2013 17:31:10 -0400
From: Daniel Fisher <dfisher at vt.edu>
Subject: Re: login.config to use private-CA-issued certificate
To: Shib Users <users at shibboleth.net>
Message-ID:
<CAFC6YwSMHca9h8cNTE9=h5M3HBw6wfAaoKE=5+s-2w9s6uLhSw at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
On Tue, Jul 30, 2013 at 7:47 PM, David Bantz <dabantz at alaska.edu> wrote:
> The config below for a single server configured to trust a single imported
> server cert works (with needed assist from Daniel Fisher).
> There seem to be at least two conceivable routes to add redundancy:
>
> (A) "stacked" login modules for multiple AD server instances:
> edu.vt.middleware.ldap.jaas.LdapLoginModule sufficient
> ldapUrl="ldap://ad02.ua.ad.alaska.edu:3268"
> ?
> edu.vt.middleware.ldap.jaas.LdapLoginModule sufficient
> ldapUrl="ldap://ad03.ua.ad.alaska.edu:3268"
> ..., or
>
> (B) "failover" configuration with multiple server instances in a single
> module:
> edu.vt.middleware.ldap.jaas.LdapLoginModule sufficient
> ldapUrl="ldap://fbk-adua02.ua.ad.alaska.edu:3268 ldap://
> fbk-adua03.ua.ad.alaska.edu:3268"
>
> sslSocketFactory="{trustCertificates=file:/opt/shibboleth-idp/trustedservercerts/????}"
>
I think your own experience would indicate that (A) is the preferred
option. Failover (B) only fails over on *connection* failures. Other types
of failure modes that may be important to you won't cause the next host to
be tried. Stacked modules should be tried in order until authentication
succeeds.
--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130731/911fb502/attachment.html
------------------------------
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
End of users Digest, Vol 25, Issue 146
**************************************
More information about the users
mailing list