SV: empoyeeID value not given

[Douglas E Engert]

On 11/27/2014 1:52 AM, Pål Axelsson wrote:
>> -----Ursprungligt meddelande-----
>> Från: users-bounces at shibboleth.net [mailto:users-
>> bounces at shibboleth.net] För Cantor, Scott
>> Skickat: den 27 november 2014 04:29
>> Till: Shib Users
>> Ämne: Re: empoyeeID value not given
>>
>> On 11/26/2014 6:04 PM, Daniel Pryor wrote:
>>>> We are using port 3268 and the ldaploginmodule. We have not tried
>>>> another user, because the same user was able to query it via ldapsearch
>>>> and ldifde. Do you suggest we still try using another more
>>>> privileged user?
>>>
>>>
>>> port 3286 accesses the Global Catalog. The GC does not have all the
>>> attributes, employeeID is not it the GC. See:
>>>
>>>    http://msdn.microsoft.com/en-us/library/ms675094(v=vs.85).aspx
>>>
>>> There are ways to add it to the GC.
>>
>> Sorry for butting in, but this keeps driving me nuts...so what is the
>> point of telling people to use that port? I keep hearing "you can't use
>> 389 with AD because some data won't be there" and then I see people say
>> you can't use the GC port because some data won't be there. I just don't
>> understand this.

I have not heard "you can't use 389 with AD because some data won't be there",
but that may be because site specific data needed by the IDP in not in AD by default.
In our case long before Shibboleth we already were adding that data to AD,
as other applications use AD for LDAP.

>>
>> What I really don't get is why people don't just use a freakin' database
>> and avoid all this nonsense, but let's stick to non-religious topics.

One less database...

AD is always available, backed up, replicated across campus, contained all our users
and has all the data needed by the IDP including group information.

>>
>> -- Scott
>>
>
> Hi,
>
> If I understand this correctly the Global Catalogue includes all users in
> all domains in  forest but doesn't have all user attributes.

Correct.

>
> The standard LDAP port includes all users in the domain that the questioned
> domain controller services. In a multi domain forest you just see the user
> attributes from that domain.

That depends on the baseDN. If you start at the top, like dc=mysite,dc=edu
LDAP will get referrals to the subdomains as look like dc=subdomain1,dc=mysite,dc=edu
so all can be queried. If you can start at ou=users,dc=mysite,dc=edu that is below the referrals, and
you will query only the top domain.

>
> If you have  a your users spread over multiple domains in the forest you
> should use the GC port and change what's in the GC. Otherwise use the
> standard LDAP port preferable over TLS.

Keep in mind that the sub domains may be administered by a different set of admins
so they can control access to local resources, and define local groups.
sAMAccountName is unique in a domain, but not in a forest, as are other attributes,
so be careful when querying the GC in a forest.


If you need to start at the top, (for example, all users are not in ou=users,dc=mysite,dc=edu)
but you don't want to chase the referrals, you can add:

      <dc:LDAPProperty name="edu.vt.middleware.ldap.referral" value="throw"/>
      <dc:LDAPProperty name="edu.vt.middleware.ldap.handlerIgnoreExceptions"
          value="javax.naming.LimitExceededException,javax.naming.ReferralException"/>

In our case all the users were in the top level domain, by not all under ou=users,dc=mysite,dc=edu)

>
> Pål
>
>
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>