Highlighted
Absent Member.
Absent Member.
360 views

networkAddress Attribute missing


Hello,

We're trying to implement ldap based authentication to our new content
filter. I have noticed that certain users aren't showing up in the
logs. The traffic is, but it's not resolving their username. After
doing some digging I have noticed something. I used jxplorer(ldap
browser) and found that the networkAddress attribute doesn't seem to
exist for some users. The accounts are older accounts that were created
under some version of NDS back in the late 90s. We're up to eDirectory
8.8 now. Newly created users have this attribute.

So my questions are:

1. Can I manually create the attribute for the affected users?

2. Shouldn't the schema determine what attributes a user has, and in
turn, any schema extensions over the years should have created those
attributes?

Thank you in advance,

-Ian


--
imc
------------------------------------------------------------------------
imc's Profile: https://forums.netiq.com/member.php?userid=1653
View this thread: https://forums.netiq.com/showthread.php?t=48137

Labels (1)
0 Likes
12 Replies
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing

On 07/05/2013 11:24 AM, imc wrote:
> We're trying to implement ldap based authentication to our new content
> filter. I have noticed that certain users aren't showing up in the
> logs. The traffic is, but it's not resolving their username. After
> doing some digging I have noticed something. I used jxplorer(ldap
> browser) and found that the networkAddress attribute doesn't seem to
> exist for some users. The accounts are older accounts that were created
> under some version of NDS back in the late 90s. We're up to eDirectory
> 8.8 now. Newly created users have this attribute.
>
> So my questions are:
>
> 1. Can I manually create the attribute for the affected users?


I think you are asking if you can create the attribute value, not the
attribute itself. This matters because the original question would be a
schema question, but Network Address is part of the User base class, so
there is no need to add it as an optional attribute on the class. The
value, however, is populated during login. LDAP authentication systems
will usually login and then logout again immediately. Perhaps your
content filter works differently, and if so then that would explain why
some users work. Why do other users not work, though.... that's not clear
to me yet. Can you verify both new and old users are actually part of the
'User' class (and not 'Person' or something custom)?

> 2. Shouldn't the schema determine what attributes a user has, and in
> turn, any schema extensions over the years should have created those
> attributes?


Yes, see above. Unless your schema is very odd, this is an optional
attribute for all users. If you can export a working and broken user that
would be very helpful. Also, can you help us understand if there is
anything at all that would cause some users (regardless of age) to
authenticate against one server, while other users authenticate against
another? For example, LDAP Proxy, a layer four switch (sends some traffic
to this box, other traffic to another), DNS, or just close replicas for
some users based on geography?

Good luck.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing


AB,

Thanks for the response. Both users are part of the User base class, at
least that what it says in iMonitor. The reason I figured it was some
user based issue was because if I log in on a machine, the attribute
value is populated while if my boss logs into the same machine, the
attribute for his user is not populated.

The username not showing up in the content filter is just a symptom, but
the real problem is that attribute not being populated. All the content
filter does is read the network address property. I'm guessing it does
some search for the IP in the network address field and matches that to
the user that shares that value. Regarding who authenticates to what
server, there is no good real answer. Whoever is working on a machine
just happened to select any of the replica servers to authenticate
against. I have no WAN considerations so there are no real reason why
one server is selected or another.

How do I export the users to compare?

ab;231187 Wrote:
> On 07/05/2013 11:24 AM, imc wrote:
> > We're trying to implement ldap based authentication to our new

> content
> > filter. I have noticed that certain users aren't showing up in the
> > logs. The traffic is, but it's not resolving their username. After
> > doing some digging I have noticed something. I used jxplorer(ldap
> > browser) and found that the networkAddress attribute doesn't seem to
> > exist for some users. The accounts are older accounts that were

> created
> > under some version of NDS back in the late 90s. We're up to

> eDirectory
> > 8.8 now. Newly created users have this attribute.
> >
> > So my questions are:
> >
> > 1. Can I manually create the attribute for the affected users?

>
> I think you are asking if you can create the attribute value, not the
> attribute itself. This matters because the original question would be
> a
> schema question, but Network Address is part of the User base class, so
> there is no need to add it as an optional attribute on the class. The
> value, however, is populated during login. LDAP authentication systems
> will usually login and then logout again immediately. Perhaps your
> content filter works differently, and if so then that would explain why
> some users work. Why do other users not work, though.... that's not
> clear
> to me yet. Can you verify both new and old users are actually part of
> the
> 'User' class (and not 'Person' or something custom)?
>
> > 2. Shouldn't the schema determine what attributes a user has, and in
> > turn, any schema extensions over the years should have created those
> > attributes?

>
> Yes, see above. Unless your schema is very odd, this is an optional
> attribute for all users. If you can export a working and broken user
> that
> would be very helpful. Also, can you help us understand if there is
> anything at all that would cause some users (regardless of age) to
> authenticate against one server, while other users authenticate against
> another? For example, LDAP Proxy, a layer four switch (sends some
> traffic
> to this box, other traffic to another), DNS, or just close replicas for
> some users based on geography?
>
> Good luck.



--
imc
------------------------------------------------------------------------
imc's Profile: https://forums.netiq.com/member.php?userid=1653
View this thread: https://forums.netiq.com/showthread.php?t=48137

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing

On 07/05/2013 12:14 PM, imc wrote:
> Thanks for the response. Both users are part of the User base class, at
> least that what it says in iMonitor. The reason I figured it was some
> user based issue was because if I log in on a machine, the attribute
> value is populated while if my boss logs into the same machine, the
> attribute for his user is not populated.


iMonitor is probably the most-honest tool you'll find for these types of
things; trust it.

> The username not showing up in the content filter is just a symptom, but
> the real problem is that attribute not being populated. All the content
> filter does is read the network address property. I'm guessing it does
> some search for the IP in the network address field and matches that to
> the user that shares that value. Regarding who authenticates to what
> server, there is no good real answer. Whoever is working on a machine
> just happened to select any of the replica servers to authenticate
> against. I have no WAN considerations so there are no real reason why
> one server is selected or another.


How is your tree partitioned, if at all beyond the [root] partition? Do
all servers hold replicas of partitions of both your object as well as
your boss's (assuming they are in different containers and partitions)?

> How do I export the users to compare?


I'd use ldapsearch personally, which may look like the following at the
server console or a decent workstation:

Code:
----------
ldapsearch -x -D 'cn=admin,o=context' -W -b 'cn=yourUser,o=here'
----------

Depending on your setup that may or may not work, such as if you have
'Require TLS for Simple Binds with Passwords' enabled, and if not familiar
with the tools I'd either search the forums for how to do this or, better
yet, download Apache Directory Studio and point it to your servers. Use
SSL (TCP 636 instead of TCP 389) and run it from your workstation. This
is a great tool that lets you browse the tree in a way that will be
familiar. Once you find your user object you should be able to
right-click on it and export it to an LDIF (LDAP file format basically)
which can be posted here. Try to not remove too much if possible.

It may be worth trying an iManager login with your boss. If that happens
does the network address attribute get populated during that session at
all? With any of these tests are you seeing your boss's modification
timestamp (iMonitor shows it) changing to the present due to current
modifications as a result of the login? Any 'Not Present' values in the
Network Address attribute indicating it was there but is now gone (will
need to be quick in iMonitor to see this, probably).

Good luck.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing


AB,

The boss went on vacation so I don't have his account to test with.
However, I am experiencing the problem with another user. In this case,
the user's network address field is being populated according to
iManager....but still not showing up in the filter logs. I can log into
the same exact machine with my own account and the logging works
perfectly. As far as the partitioning goes, all of these particular
users/server are in the root partition. There are some partitions, but
they shouldn't be a factor here.

Would it still be worth posting the LDIF files even if I can confirm the
network address field is being populated for the other problem user?



ab;231195 Wrote:
> On 07/05/2013 12:14 PM, imc wrote:
> > Thanks for the response. Both users are part of the User base class,

> at
> > least that what it says in iMonitor. The reason I figured it was some
> > user based issue was because if I log in on a machine, the attribute
> > value is populated while if my boss logs into the same machine, the
> > attribute for his user is not populated.

>
> iMonitor is probably the most-honest tool you'll find for these types of
> things; trust it.
>
> > The username not showing up in the content filter is just a symptom,

> but
> > the real problem is that attribute not being populated. All the

> content
> > filter does is read the network address property. I'm guessing it

> does
> > some search for the IP in the network address field and matches that

> to
> > the user that shares that value. Regarding who authenticates to what
> > server, there is no good real answer. Whoever is working on a machine
> > just happened to select any of the replica servers to authenticate
> > against. I have no WAN considerations so there are no real reason why
> > one server is selected or another.

>
> How is your tree partitioned, if at all beyond the [root] partition? Do
> all servers hold replicas of partitions of both your object as well as
> your boss's (assuming they are in different containers and partitions)?
>
> > How do I export the users to compare?

>
> I'd use ldapsearch personally, which may look like the following at the
> server console or a decent workstation:
>
> Code:
> ----------
> ldapsearch -x -D 'cn=admin,o=context' -W -b 'cn=yourUser,o=here'
> ----------
>
> Depending on your setup that may or may not work, such as if you have
> 'Require TLS for Simple Binds with Passwords' enabled, and if not
> familiar
> with the tools I'd either search the forums for how to do this or,
> better
> yet, download Apache Directory Studio and point it to your servers. Use
> SSL (TCP 636 instead of TCP 389) and run it from your workstation. This
> is a great tool that lets you browse the tree in a way that will be
> familiar. Once you find your user object you should be able to
> right-click on it and export it to an LDIF (LDAP file format basically)
> which can be posted here. Try to not remove too much if possible.
>
> It may be worth trying an iManager login with your boss. If that
> happens
> does the network address attribute get populated during that session at
> all? With any of these tests are you seeing your boss's modification
> timestamp (iMonitor shows it) changing to the present due to current
> modifications as a result of the login? Any 'Not Present' values in the
> Network Address attribute indicating it was there but is now gone (will
> need to be quick in iMonitor to see this, probably).
>
> Good luck.



--
imc
------------------------------------------------------------------------
imc's Profile: https://forums.netiq.com/member.php?userid=1653
View this thread: https://forums.netiq.com/showthread.php?t=48137

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing

Can you confirm how you know that the value is being populated? I believe
you if you're sure, but it's interesting that it would be there and then
your network tool thingy would not see it. If the verification is merely
the modificationTime being updated then that may not be enough, but if you
actually see the deleted value ('Not Present') in iMonitor then that's a
good sign. The value needs to be present, though, for LDAP to return it.

Hmmm.............

In the end David's probably going to tell you that this attribute is not
terribly reliable for a number of reasons. I haven't worked with it as
much as he has, so finish his checks since they are probably more directed
than mine.

Good luck.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing

On Fri, 05 Jul 2013 17:24:02 +0000, imc wrote:

> We're trying to implement ldap based authentication to our new content
> filter. I have noticed that certain users aren't showing up in the
> logs. The traffic is, but it's not resolving their username. After
> doing some digging I have noticed something. I used jxplorer(ldap
> browser) and found that the networkAddress attribute doesn't seem to
> exist for some users.


You might search the forums here for "network address". It'll save me
some typing if you re-read previous discussions of its usefulness.


> The accounts are older accounts that were created
> under some version of NDS back in the late 90s. We're up to eDirectory
> 8.8 now. Newly created users have this attribute.


Doesn't matter.


> So my questions are:
>
> 1. Can I manually create the attribute for the affected users?


No, not really.


> 2. Shouldn't the schema determine what attributes a user has, and in
> turn, any schema extensions over the years should have created those
> attributes?


Schema defines what attributes an object *can* have, not the attributes
that it necessarily does have. You don't have a schema problem here.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing


I guess another question I would have would be can the network address
be read by a single server? In other words, if I have 8 servers with
read/write or the master replica on them, do I need to configure all 8
in the web filter or would an LDAP call for network address work by
using any one of the replicas as a "proxy" regardless of what server a
user authenticated against?


--
imc
------------------------------------------------------------------------
imc's Profile: https://forums.netiq.com/member.php?userid=1653
View this thread: https://forums.netiq.com/showthread.php?t=48137

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing

On Mon, 08 Jul 2013 18:34:02 +0000, imc wrote:

> I guess another question I would have would be can the network address
> be read by a single server?


Yes. It's just a regular attribute, so any server can read it.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing


Thanks for the responses. I may have bumbled my way to a solution. The
UID is not set for older users, and that's the attribute that the web
filter is using to resolve the login id. Setting that for this
particular user seems to have worked.

As an aside, I'm a bit bothered by the idea that the network address
isn't reliable. Why does the attribute exist if it's not going to work?
Why would anyone who needs to pull this attribute with any sort of
confidence be using eDirectory then? I'm not saying you're wrong Dave,
I'm saying that if you're correct, then that is absurd.


--
imc
------------------------------------------------------------------------
imc's Profile: https://forums.netiq.com/member.php?userid=1653
View this thread: https://forums.netiq.com/showthread.php?t=48137

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing

On Mon, 08 Jul 2013 19:54:02 +0000, imc wrote:

> Thanks for the responses. I may have bumbled my way to a solution. The
> UID is not set for older users, and that's the attribute that the web
> filter is using to resolve the login id. Setting that for this
> particular user seems to have worked.


Ah. Yes, that could matter. Sometimes it helps to examine the
application's version of the LDAP search filter to see what it's looking
for. Sometimes the app doesn't easily expose that, so watching it in
ndstrace with all of the LDAP trace options turned on can be educational.


> As an aside, I'm a bit bothered by the idea that the network address
> isn't reliable. Why does the attribute exist if it's not going to work?


See the previous discussions of "stuck network address". I'm told that it
works. My experience with it says otherwise. I've had multiple SRs open
on the issue, dating back 10 years or more now. Support has told me that
no other customers have reported any problems. A detailed analysis of how
it works shows that there are several large holes in its design, so that
no implementation can ever be proved to be 100% reliable, but since
"nobody" other than me is complaining, there's not much priority on
changing it.


> Why would anyone who needs to pull this attribute with any sort of
> confidence be using eDirectory then?


I have no satisfactory answer to this question.


> I'm not saying you're wrong Dave,
> I'm saying that if you're correct, then that is absurd.


I cannot disagree with your assessment of the situation, either.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: networkAddress Attribute missing


dgersic;231230 Wrote:
> On Fri, 05 Jul 2013 17:24:02 +0000, imc wrote:
>
> > We're trying to implement ldap based authentication to our new content
> > filter. I have noticed that certain users aren't showing up in the
> > logs. The traffic is, but it's not resolving their username. After
> > doing some digging I have noticed something. I used jxplorer(ldap
> > browser) and found that the networkAddress attribute doesn't seem to
> > exist for some users.

>
> You might search the forums here for "network address". It'll save me
> some typing if you re-read previous discussions of its usefulness.
>
>


Hey Dave. I did do a cursory search prior to posting but didn't see
something jump out other than the format changing over the years.


--
imc
------------------------------------------------------------------------
imc's Profile: https://forums.netiq.com/member.php?userid=1653
View this thread: https://forums.netiq.com/showthread.php?t=48137

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.