Need assistance releasing Active Directory "employeeID" attribute

IAM David Bantz dabantz at alaska.edu
Tue Jan 24 12:54:39 EST 2017


AD admins can put other attributes (employeeID or others) into the general
catalog.

see https://wiki.shibboleth.net/confluence/display/SHIB2/LdapServerIssues

David Bantz

On Tue, Jan 24, 2017 at 5:13 AM, Edward Patri <Edward.Patri at csi.cuny.edu>
wrote:

> Hi Douglas,
>
> Thank you for all your assistance on this. I was able to resolve the issue.
>
> It seems that the shibboleth Auth was working over port 636 but the
> resolver was defined to use port 3269 instead of 636. Which explains why I
> couldn’t resolve the employeeID attribute since it is not part of the
> global catalog. Once I changed the port everything started working the way
> it should.
>
> ​​​​​
> Edward Patri
> Networking Services
> CUNY - College of Staten Island
> 2800 Victory Blvd 2A-300
> Staten Island, NY 10314
> Office: (718) 982-2705
> Edward.Patri at csi.cuny.edu
>
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E
> Engert
> Sent: Tuesday, January 24, 2017 8:26 AM
> To: users at shibboleth.net
> Subject: Re: Need assistance releasing Active Directory "employeeID"
> attribute
>
>
>
> On 1/23/2017 9:55 PM, Edward Patri wrote:
> > Hi Douglas,
> >
> > You are correct. I am trying to release the AD attribute employeeID. Do
> you have any suggestions on how I can accomplish this?
>
> First of all, does the IDP ldap query return the attribute? Look at the
> logs.
> look at the logs to see what is sent to the SP. Does it send other
> attributes, but not the employeeID.
>
> If not, rather then using idp.attribute.resolver.LDAP.returnAttributes= *
> list out all the attributes you need.
>
> If it is returned, try using:
> <resolver:AttributeEncoder xsi:type="enc:SAML2String"
> nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
> name="employeeID" /> i.e. don't use the OID, as the SP may not understand
> it.
>
> google for idp.attribute.resolver.LDAP.returnAttributes
>
> What is in the myLDAP dataconnector? Is it substituting the
> idp.attribute.resolver.LDAP.returnAttributes?
>
> (This is off the top of my head. I am retired, but in 2014 I did use the
> employeeID from AD 2008.)
>
>
>
> >
> > -----Original Message-----
> > From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas
> > E Engert
> > Sent: Monday, January 23, 2017 5:51 PM
> > To: users at shibboleth.net
> > Subject: Re: Need assistance releasing Active Directory "employeeID"
> > attribute
> >
> >
> >
> > On 1/23/2017 4:09 PM, Matt Brennan wrote:
> >> 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.
> >
> >
> > AD has employeeID which is different from employeeNumber
> >
> > https://msdn.microsoft.com/en-us/library/ms675662(v=vs.85).aspx
> >
> >>
> >> 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 <mailto: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 <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 <mailto: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 <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 <mailto:users at shibboleth.net
> >>
> >>     > Cc: Stanley Tse <Stanley.Tse at csi.cuny.edu <mailto:
> 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
> >> <mailto:DEEngert at gmail.com>>
> >>
> >>     --
> >>     To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>
> >>     --
> >>     To unsubscribe from this list send an email to
> >> users-unsubscribe at shibboleth.net
> >> <mailto:users-unsubscribe at shibboleth.net>
> >>
> >>
> >>
> >>
> >
>
> --
>
>   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/20170124/ebf4bf02/attachment.html>


More information about the users mailing list