Need assistance releasing Active Directory "employeeID" attribute

[Matt Brennan]

Actually, I believe the attribute identifier you are using is incorrect. I
believe, for SAML2, it should be "urn:oid:2.16.840.1.113730.3.1.3". For
SAML1, it should be "urn:mace:dir:attribute-def:employeeNumber". Spec is
available at "http://www.faqs.org/rfcs/rfc2798.html". But that shouldn't
effect what attributes you are seeing released in a test script; it would
just affect the ability of the SP to use the attributes.

Are you seeing any related log messages, either when loading the
configuration or when sending the assertion?

Anything at all in the logs related to the attribute?

-Matt

On Mon, Jan 23, 2017 at 4:40 PM, Edward Patri <Edward.Patri at csi.cuny.edu>
wrote:

> Hi Doug,
>
> I am connection to our Domain Controller over port 636 not over global
> catalog 3268. I verified using softerra ldap broswer that the shibboleth
> account can read the attribute employeeID. Also I verified that employeeID
> is populated.
>
> I am currently running IDP version 3.2.1.0 not sure if it makes a
> difference.
>
>
>
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E
> Engert
> Sent: Monday, January 23, 2017 4:30 PM
> To: users at shibboleth.net
> Subject: Re: Need assistance releasing Active Directory "employeeID"
> attribute
>
>
>
> On 1/23/2017 2:14 PM, Edward Patri wrote:
> > Hi Scott,
> >
> > I have configured our ldap.properties to return all attributes using the
> following command.
> >
> > idp.attribute.resolver.LDAP.returnAttributes= *
>
> Note employeeID is not the global catalog.
>
> It may also not be readable by the user.
>
> employeeID needs to be entered by your AD admins, are you sure the
> accounts have this attribute?
>
> AD has hundreds of attributes, I found it was best to list only the
> attributes you want.
>
> Also found testing ldap queries of AD using openldap and ADSI edit to be
> very helpful to see what is really returned and if the accounts have the
> attribute set.
>
> With IDP 2 I used to create a username for only one specific SP and used:
> <resolver:AttributeEncoder xsi:type="enc:SAML2String"
> nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
> name="username" />
>
> >
> > I have removed the SAML1 string line and as for the SAML 2.0 isnt that
> line correct?
> >
> > I am using the aacli.bat script to test which attributes I am releasing
> to a certain SP and the employeeID attribute is not being released although
> it is configured to be released in the attribute-filter.xml file.
> >
> > I am still getting used to shibboleth and any assistance would be
> greatly appreciated.
> >
> > ​​​​​
> >
> > -----Original Message-----
> > From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor,
> Scott
> > Sent: Monday, January 23, 2017 3:06 PM
> > To: Shib Users <users at shibboleth.net>
> > Cc: Stanley Tse <Stanley.Tse at csi.cuny.edu>
> > Subject: RE: Need assistance releasing Active Directory "employeeID"
> attribute
> >
> >>         <resolver:AttributeEncoder xsi:type="enc:SAML1String"
> >> name="urn:mace:dir:attribute-def:employeeID" encodeType="false" />
> >
> > You cannot make up names yourself like that, you don't own that
> namespace. And you don't need SAML 1.1 support, so don't worry about it.
> Its name in any case would be the same as in SAML 2.0.
> >
> > As for the rest, you need to actually describe a specific problem to get
> help. What did the log tell you? You certainly didn't just change that
> alone? You can't manufacture an attribute out of thin air. If you tell it
> to get it from LDAP, then your LDAP connector has to retrieve it. Some
> people do a search for all attributes but many don't.
> >
> > -- Scott
> >
>
> --
>
>   Douglas E. Engert  <DEEngert at gmail.com>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170123/f3b283f5/attachment-0001.html>