DeviceID (save) - doesn't save when authenticating with mail attribute

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

DeviceID (save) - doesn't save when authenticating with mail attribute

Brad Tarisznyas
Hi All,

Configuring DeviceID (match) and DeviceID (Save) works without a hitch when using uid as the authenticating attribute in the LDAP module.
However when adding mail to "Attributes Used to Search for a User to be Authenticated” and using email as the authenticating attribute the DeviceID match and save modules fail to lookup and write the profiles to the user’s account.
If I remove the device modules….authentication works fine.

The only way I have got this to work so far is to use “mail” as the "LDAP Users Search Attribute” in the datastore config. But then when creating users via the console it creates them with a DN of mail=xxxx,dc=example,dc=com.

Anyone run across this?

This is on OpenAM 5.

Cheers Brad

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DeviceID (save) - doesn't save when authenticating with mail attribute

Brad Tarisznyas
debug log shows the following:

ERROR: Cannot get User's Device Print Profiles attribute. java.lang.NullPointerException


On 16 May 2017, at 11:45 am, Brad Tarisznyas <[hidden email]> wrote:

Hi All,

Configuring DeviceID (match) and DeviceID (Save) works without a hitch when using uid as the authenticating attribute in the LDAP module.
However when adding mail to "Attributes Used to Search for a User to be Authenticated” and using email as the authenticating attribute the DeviceID match and save modules fail to lookup and write the profiles to the user’s account.
If I remove the device modules….authentication works fine.

The only way I have got this to work so far is to use “mail” as the "LDAP Users Search Attribute” in the datastore config. But then when creating users via the console it creates them with a DN of mail=xxxx,dc=example,dc=com.

Anyone run across this?

This is on OpenAM 5.

Cheers Brad


_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DeviceID (save) - doesn't save when authenticating with mail attribute

Bernhard Thalmayr
In reply to this post by Brad Tarisznyas
OpenAM is not an IdM tool, it does not allow you to create LDAP entries
as you want.

OpenAM does not act on LDAP entries, it consumes identity information
from configured user data stores and builds identity subjects (in memory
on the fly).

--> There is no DN shown in OpenAM console, that's LDAP. It's an UUID.

I agree that it's not widely known how IdRepo really works. This leads
to the fact that LDAP-terms are used all over, although it's not related.

Some of this is due to legacy, before the introduction of the IdRepo
API, some is due to ignorance.

-Bernhard

Am 16/05/17 um 11:45 schrieb Brad Tarisznyas:

> Hi All,
>
> Configuring DeviceID (match) and DeviceID (Save) works without a hitch
> when using uid as the authenticating attribute in the LDAP module.
> However when adding mail to "Attributes Used to Search for a User to be
> Authenticated” and using email as the authenticating attribute the
> DeviceID match and save modules fail to lookup and write the profiles to
> the user’s account.
> If I remove the device modules….authentication works fine.
>
> The only way I have got this to work so far is to use “mail” as the
> "*LDAP Users Search Attribute” *in the datastore config. But then when
> creating users via the console it creates them with a DN of
> mail=xxxx,dc=example,dc=com.
>
> Anyone run across this?
>
> This is on OpenAM 5.
>
> Cheers Brad
>
>
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
>


--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699

[hidden email] - Solution Architect
http://www.xing.com/profile/Bernhard_Thalmayr
http://de.linkedin.com/in/bernhardthalmayr

This e-mail may contain confidential and/or privileged information.If
you are not the intended recipient (or have received this email in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DeviceID (save) - doesn't save when authenticating with mail attribute

Andy Cory-2
Hi Brad

If you have the Authentication Naming Attribute set to mail, I believe that needing to have the LDAP Users Search Attribute also set to mail is expected in order to ensure the device profile is saved to LDAP. (I’ve come across a problem whereby the device profiles do not show on the dashboard using this configuration, but they are persisted to OpenDJ correctly. I don’t know if I was just unlucky or if this is a reproducible issue.)

My view is that the deviceID match & save seems to be working OK for you, and the limitations of provisioning users from the OpenAM admin console is a different problem. Bernhard’s point is entirely valid, and often repeated – the console will provision new identities as a convenience, but as soon as you want to do anything even slightly off-piste with your identities (like using an attribute other than the Authentication Naming Attribute used as the RDN) you exceed its functionality. If you don’t use an IDM tool to provision your users then a vanilla LDIF import is going to be superior to using OpenAM in getting your identities to look the way you want them.

Andy

On 16/05/2017, 20:29, "[hidden email] on behalf of Bernhard Thalmayr" <[hidden email] on behalf of [hidden email]> wrote:

    OpenAM is not an IdM tool, it does not allow you to create LDAP entries
    as you want.

    OpenAM does not act on LDAP entries, it consumes identity information
    from configured user data stores and builds identity subjects (in memory
    on the fly).

    --> There is no DN shown in OpenAM console, that's LDAP. It's an UUID.

    I agree that it's not widely known how IdRepo really works. This leads
    to the fact that LDAP-terms are used all over, although it's not related.

    Some of this is due to legacy, before the introduction of the IdRepo
    API, some is due to ignorance.

    -Bernhard

    Am 16/05/17 um 11:45 schrieb Brad Tarisznyas:
    > Hi All,
    >
    > Configuring DeviceID (match) and DeviceID (Save) works without a hitch
    > when using uid as the authenticating attribute in the LDAP module.
    > However when adding mail to "Attributes Used to Search for a User to be
    > Authenticated” and using email as the authenticating attribute the
    > DeviceID match and save modules fail to lookup and write the profiles to
    > the user’s account.
    > If I remove the device modules….authentication works fine.
    >
    > The only way I have got this to work so far is to use “mail” as the
    > "*LDAP Users Search Attribute” *in the datastore config. But then when
    > creating users via the console it creates them with a DN of
    > mail=xxxx,dc=example,dc=com.
    >
    > Anyone run across this?
    >
    > This is on OpenAM 5.
    >
    > Cheers Brad
    >
    >
    > _______________________________________________
    > Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
    > OpenAM mailing list
    > [hidden email]
    > https://lists.forgerock.org/mailman/listinfo/openam
    >


    --
    Painstaking Minds
    IT-Consulting Bernhard Thalmayr
    Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
    Tel: +49 (0)8062 7769174
    Mobile: +49 (0)176 55060699

    [hidden email] - Solution Architect
    http://www.xing.com/profile/Bernhard_Thalmayr
    http://de.linkedin.com/in/bernhardthalmayr

    This e-mail may contain confidential and/or privileged information.If
    you are not the intended recipient (or have received this email in
    error) please notify the sender immediately and delete this e-mail. Any
    unauthorized copying, disclosure or distribution of the material in this
    e-mail is strictly forbidden.
    _______________________________________________
    Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
    OpenAM mailing list
    [hidden email]
    https://lists.forgerock.org/mailman/listinfo/openam






This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. If you are not the intended recipient, any use, disclosure, copying or forwarding of this email and/or its attachments is unauthorised. If you have received this email in error please notify the sender by email and delete this message and any attachments immediately. Nothing in this email shall bind the Company or any of its subsidiaries or businesses in any contract or obligation, unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, company number 02150618 and whose registered office is at 37 Carr Lane, Hull, HU1 3RE.

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Loading...