Network Address attribute different in OES Linux to NetWare
Simon Tideswell
someone called Serg, with subject line "About Field "Network Address" in
the OES_SP2". The post was originally made in the OES Linux,
Administration Forum, but I was advised to repost here.
The question relates to the difference between the way the user's
NetworkAddress attribute is registered in eDirectory in OES Linux and
NetWare: if the user's server is OES Linux the NetworkAddress (when
viewed in ConsoleOne) ends up being something like TCP: 10.20.4.15,
whereas if the user's server is NetWare the NetworkAddress would be IP:
10.20.4.15. Although this doesn't seem like a big deal there is also some
unpredictable stuff stored in the NetworkAddress attribute in the OES
Linux case: this is not apparent when viewing in ConsoleOne but is easily
seen when using, e.g., Perl's Net::LDAP and Net::LDAP::LDIF to extract the
NetworkAddress (comes out base64 encoded). The paras below explain why
this is such a problem.
I have just stumbled on this behaviour and it is very undesirable. I use
a perl script to authenticate users to squid based on their Network
Address attribute in eDirectory. This will stop working if I migrate to
OES Linux everywhere.
The issue can best be explained by looking at an example of the LDAP
search filter I use to find the user with a particular IP.
At the moment (for NetWare) I use filter ...
(networkAddress = \49\35\0A\14\04\0F)
... for instance to check for user with IP address 10.20.4.15 (stored as
1#ascii(10)ascii(20)ascii(4)ascii(15)). Here 1# (or Hex \49\35) signifies
IP, the hash is "just there" as a separator or something and the four
octets of the IP are stored as RAW unsigned chars).
However with OES Linux the networkAddress attribute of a connected
client workstation is not listed in the same way: the connection type
is not IP but TCP and is represented by 9# (or Hex \57\35), the four
octets are represented as before but there is a bit of stuff in between
which seems to be unpredictable - possibly the TCP/IP port number? So the
filter becomes ...
(networkAddress = \57\35\??\??\0A\14\04\0F)
... where I cannot predict the two unsigned chars \??\??. I cannot replace
that segment of the search filter with a wildcard as - not sure if this is
an eDirectory or LDAP lmitation - it throws errors (viewable in ndstrace
as "substring match used on unsupported syntax").
Unless I can somehow predict what value to use for \?\? then my perl
script and hence my squid authentication will be broken when I move to OES
Linux. I can code around this but this will start to get fairly elaborate
and I'd prefer not to.
Please help me someone!
Simon
David Gersic
<stid...@networkten.com.au> wrote:
>The question relates to the difference between the way the user's
>NetworkAddress attribute is registered in eDirectory in OES Linux and
>NetWare: if the user's server is OES Linux the NetworkAddress (when
>viewed in ConsoleOne) ends up being something like TCP: 10.20.4.15,
>whereas if the user's server is NetWare the NetworkAddress would be IP:
>10.20.4.15.
Your search is _already_ broken, it's just that you hadn't noticed it
until now. The Network Address attribute is what they call a
"structured" attribute containing multiple parts. The first, as you've
noticed, is a network type (1 = IP, 9 = TCP), which specifies the format
of the remaining data in the attribute. You're only looking for IP,
which is fundamentally wrong as the connection type could be IP, IPX,
TCP, SNA, etc. here.
Once you have the network type, then you can parse the remaining parts
of the structure.
>Although this doesn't seem like a big deal there is also some
>unpredictable stuff stored in the NetworkAddress attribute in the OES
>Linux case:
You're seeing the port number. That's to be expected for a TCP
connection.
>this is not apparent when viewing in ConsoleOne but is easily
>seen when using, e.g., Perl's Net::LDAP and Net::LDAP::LDIF to extract the
>NetworkAddress (comes out base64 encoded).
There's some sample Perl source on CoolSolutions that shows how to
handle parsing the Network Address.
>I have just stumbled on this behaviour and it is very undesirable. I use
>a perl script to authenticate users to squid based on their Network
>Address attribute in eDirectory. This will stop working if I migrate to
>OES Linux everywhere.
>
>The issue can best be explained by looking at an example of the LDAP
>search filter I use to find the user with a particular IP.
>
>At the moment (for NetWare) I use filter ...
>(networkAddress = \49\35\0A\14\04\0F)
That this is working at all is just a happy coincidence.
>... for instance to check for user with IP address 10.20.4.15 (stored as
>1#ascii(10)ascii(20)ascii(4)ascii(15)). Here 1# (or Hex \49\35) signifies
>IP, the hash is "just there" as a separator or something and the four
>octets of the IP are stored as RAW unsigned chars).
The 1 is "IP". The hash is a data separator used to stuff an internal
structured attribute in to a string format that LDAP can understand.
---------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
I'm tired of receiving rubbish in my mailbox, so the E-mail address is
munged to foil the junkmail bots. Humans will figure it out on their own.
Simon Tideswell
> Your search is _already_ broken, it's just that you hadn't noticed it
> until now. The Network Address attribute is what they call a
> "structured" attribute containing multiple parts. The first, as you've
> noticed, is a network type (1 = IP, 9 = TCP), which specifies the format
> of the remaining data in the attribute. You're only looking for IP,
> which is fundamentally wrong as the connection type could be IP, IPX,
> TCP, SNA, etc. here.
age if anyone still did). _All_ Windows NCP clients connecting to the
NetWare servers end up with an IP (1#) entry for the networkAddress, so
that's all my filter needs to search for - if this was so broken I'd have
users complaining that they couldn't access the Internet, rest assured.
The only client PC's that don't have an IP (1#) networkAddress attribute
are the users at the sole location that has an OES Linux server only:
these end up with a TCP (9#) entry for the networkAdress.
> Once you have the network type, then you can parse the remaining parts
> of the structure.
I think you are not understanding the nature of the problem: I am well
aware that I can parse the networkAddress attribute out of eDirectory into
its constituent components, that is trivial. But that is not what I am
trying to do: I am trying to search (over LDAP) for an entry that has a
certain IP address which is quite different. The search filter cannot be
constructed to find the address because I can never expect to know what
client port the NCP connection is using and because the networkAddress
attribute does not allow for a substring wildcard search.
> There's some sample Perl source on CoolSolutions that shows how to
> handle parsing the Network Address.
>
I have seen plenty of such code that can be used to read out addresses
from eDirectory, I'm not aware of any that can help me construct the kind
of LDAP search filter I require: if you could direct me to some it'd be
very much appreciated.
Rant:-
On a separate note, your overall response is a typical one that a poster
receives on the forums. Novell bigots tend to be very condescending and
dismissive of most of the posts made. It is almost as though a Novell
bigot cannot bear to hear anything negative about Novell software and will
consequently close their mind to the question being asked and then attempt
to pour disdainful scorn on the poster. I've seen this develop into
"back and forth" arguments by posters and respondents in the
forums which, although sometimes entertaining, don't assist anyone, nor do
they result in Novell improving their reputation for defective and
inadequate code. I am thinking my resolution to this issue will probably
involve me populating a MySQL database with user's networkAddress
attributes using IDM. Then I will be able to use a perl script to query
the database and authenticate the user from that. This will be a fair
amount of effort that I was hoping to avoid. I am not an idiot as your
reply seems to indicate and you clearly haven't fully understood the
question I was asking. Your response is the kind of response that
continues to convince me that these forums are usually a waste of time
because the dialogues that occur are so superficial and misinformed. From
my perspective Novell seriously lacks credibility as a software firm, as
the poor fool who is responsible for looking after our GroupWise 7 system
I can tell you that I have never experienced a more clumsy and
imcompetently delivered product update than that. It is high time Novell
listen to these concerns and improve their product and support. Taking
time to understand posts like mine, recognising the real issue and then
giving pertinent advice would go some way toward improving customer
confidence.
End Rant.
Merry Christmas all.
Andrew C Taubman
with them apart from being a valued member of this voluntary community.
Your rant about Novell product quality, support, and other matters
outside his control is entirely misdirected.
Point 2: You say _we're_ condescending. Read your own post again - we
are bigoted, disdainful, scornful, lacking credibility, superficial, and
misinformed according to you. Attacking those you wish to get help from
is simply self-defeating, not to mention rude. If David responds to you
in any constructive way after the way you've treated him, well, he'd be
a bigger man than I am. And, he did /not/ say or imply that you are an
idiot.
As far as your issue goes, your complaint seems to be that although eDir
correctly stores the network address with the protocol type, this is
inconvenient for your search that was set up on the assumption it would
always be IP. Your rant seems to imply this is a bug, but it's not, it's
working as designed. To address your issue Novell would have to 1/
change eDir to store it as if it was IP although it was really TCP, or
2/ change OES/Linux to use IP instead of TCP.
I guess you are after the latter, but posting in a voluntary support
forum is never going to achieve a design change of this nature. If you
have any sort of official support standing with Novell I suggest you
raise it there; you can also open an enhancement request at
http://support.novell.com/enhancement/index.html?sourceidint=suplnav4a_enhancement
What I could do for you is ask why OES/Linux uses TCP not IP, but
whatever the answer is will not affect your situation, of course.
--
Andrew C Taubman
Novell Support Forums Volunteer SysOp
http://support.novell.com/forums
(Sorry, support is not provided via e-mail)
Opinions expressed above are not
necessarily those of Novell Inc.
Jim Henderson
> Unless I can somehow predict what value to use for \?\? then my perl
> script and hence my squid authentication will be broken when I move to OES
> Linux. I can code around this but this will start to get fairly elaborate
> and I'd prefer not to.
I've done a little work with integrating Squid with eDir, and am curious
(more than anything) what the requirement is to parse on IP address - I've
always done this using group memberships myself, which seems to be a very
clean way to do this. I can't personally think of a situation where you'd
restrict a user from going to the 'net from one machine but not another.
To your question, though, David is correct - it's a structured data type,
so you first have to parse the structure and then work it out from there.
While your network might only contain TCP/IP, the network address data
type is used for all types of network addresses, so the structure has to
allow for different types of network addresses. Given that it's
structured, wildcards would have different meanings depending on the
network address type.
This data type is even used for predicate data when looking at search
statistics. The data type itself doesn't lend itself to wildcard searches
because of its structured nature.
Jim
--
Jim Henderson, CNA6, CDE, CNI, LPIC-1
Novell Training Services
Simon Tideswell
>
> I've done a little work with integrating Squid with eDir, and am curious
> (more than anything) what the requirement is to parse on IP address - I've
> always done this using group memberships myself, which seems to be a very
> clean way to do this. I can't personally think of a situation where you'd
> restrict a user from going to the 'net from one machine but not another.
squid by typing in their username and password. Our users are not used to
doing this and would complain at being required to do this - we used to
user Novell BorderManager and the client trust key to do this seemlessly
for the user. The idea behind my approach is - the only thing squid knows
is the user's IP address - it then queries LDAP to see what the CN is for
the user with that IP and whether that user is a member of an appropriate
group for the kind of content they are attempting to view. This way they
can "authenticate" to squid without being required to type in a password.
The password thing is all the more irritating with IE (our corporate
standard browser) which doesn't retain username/password information
between instances as Firefox does.
> To your question, though, David is correct - it's a structured data type,
> so you first have to parse the structure and then work it out from there.
> While your network might only contain TCP/IP, the network address data
> type is used for all types of network addresses, so the structure has to
> allow for different types of network addresses. Given that it's
> structured, wildcards would have different meanings depending on the
> network address type.
>
> This data type is even used for predicate data when looking at search
> statistics. The data type itself doesn't lend itself to wildcard searches
> because of its structured nature.
I guess my point would be if IP and no port was good enough for NetWare
then why not for OES Linux? _Both_ TCP and IP addresses would be OK for
me. The port number is pretty much useless data as far as I can see and to
essentially make the networkAddress no longer a searchable attribute in
LDAP is a retrograde step. I'll work around this somehow but it seems like
a negative move for little or no good reason on Novell's part.
Simon
Jim Willeke
When a client connects to OES on Linux the networkaddress shows as a TCP
address.
If the SAME client connects to a Netware Server, it is an IP address.
Right?
If that is the case then it does appear to be another issue with how the
NetworkAddress is being used/abused and lacks any kind of logic.
Just how can you have a UDP/TCP and IP address types, seems to be
overlapping as UDP and TCP are IP addresses.
I have NetWare OES and Edirectory 8.8.1 on Suse Server and both shows
the address type as an IP address.
-jim
Simon Tideswell
still people out there using/caring about Novell .
> Why not add a second query based on TCP? You know the user involved so
> just get all network addresses and then do your own filtering outside
> LDAP.
I could do this but the LDAP search will not allow me to "wildcard" the
client port and so the search will always throw errors and fail. Besides I
don't know the user, I (squid) only know the IP address of the user at
this stage. This whole thing is designed to avoid the user needing to 'log
in' in order to use squid.
> People who actually like to help other people, for free, aren't racist,
> sexist, or discriminating in any other way. Typically the word for them
> is philanthropist. How's that for condescending?
Nicely said. However take it from me Novell folks are perceived to be
irrationally unwilling to accept criticism of Novell. This would not
matter if they could smugly sit there being correct and laughing at the
misfortunes of poor M$ admins. However the reality is these days M$
admins have a lot less to worry about than the equivalent Novell guy but
the Novell guys are still stupidly assuming they are competing against
Windows NT4 and Exchange 5.5 - I'm afraid I have to inform you that
Microsoft have moved on, I'm not so sure that Novell have.
> I'm sure glad that rant came out in here semi-anonymously because if
> that is what waited for your family and friends (or Santa
> Clause....taken out with a shotgun......so sad....) you were probably in
> for more pain than you'll receive here even with a challenging issue
> like the one you have.
It's OK, I don't take it any further I get it off my chest and express
myself and then I can relax - better get it out rather than stewing on it.
Most people think I'm a nice guy.
> As others mentioned with more grace than was deserved, submit an
> enhancement request. Use your IDM idea.
Don't worry I'll sort it out somehow, I usually do. This particular
problem would not matter were it not for the fact that I had so many other
Novell related problems that it is almost like the straw that will
break the camel's back.
Happy Holiday. May next year be the year that Novell faces up to where it
is, pulls its socks up and kicks M$ to the kerb.
Simon Tideswell
what frustrations Novell admins in the field face. I still don't feel,
when conversing with "Novellies"/"Novellophiles", that they realise how
poorly regarded Novell is and how much trouble Novell is in as a company
if it cannot reverse that trend.
I'm not implying that the different way of recording the networkAddress in
OES Linux is a bug: it's just an irritating change that I now have to code
around. It's also a change that renders a previously useful search
facility of LDAP now unusable. It's also another task I have to do when I
am already flat out chasing GroupWise bugs and NSS on OES Linux bugs - I
could have done without the additional problem to resolve.
I won't be posting an enhancement request as I can't see it ever getting
attended to: I have NSS (on Linux) defects open with Novell since June
this year and more GroupWise defects than you can poke a stick at (despite
GroupWise 7 being a 15 month old product). If Novell is struggling to fix
up these problems what hope do they have of working on additional stuff?
I'm not saying this stuff because I am a big Microsoft fan or something -
I hate M$, I want Novell to kick ass but right now Novell would probably
fall over and smash their teeth on the sidewalk whilst trying to do so.
Simon
calm...@itschristmas.com
taste in my mouth I think I need to brush my teeth first.
Don't look a gift horse in the mouth.
You get what you pay for.
You're criticizing the product because it gives you more information now
instead of less....that seems odd.
You're in a forum staffed by people looking for answers and how also like
to help other people...and you're shouting...at somebody who knows what
they're doing.
Why not add a second query based on TCP? You know the user involved so
just get all network addresses and then do your own filtering outside LDAP.
People who actually like to help other people, for free, aren't racist,
sexist, or discriminating in any other way. Typically the word for them is
philanthropist. How's that for condescending?
I'm sure glad that rant came out in here semi-anonymously because if that
is what waited for your family and friends (or Santa Clause....taken out
with a shotgun......so sad....) you were probably in for more pain than
you'll receive here even with a challenging issue like the one you have.
As others mentioned with more grace than was deserved, submit an
enhancement request. Use your IDM idea. Call Novell and see what they
have to say about it. Perhaps nobody else actually uses that attribute in
the way you mentioned and nobody has noticed the protocol change in this way.
Happy Hanukkah, but to not be a bigot, Happy Holidays.
Simon Tideswell
> When a client connects to OES on Linux the networkaddress shows as a TCP
> address.
>
> If the SAME client connects to a Netware Server, it is an IP address.
>
> Right?
David Gersic
<stid...@networkten.com.au> wrote:
>Hi David, thanks for your response.
Er, yeah, right. You seem _real_ grateful that I went to the effort of
trying to help you. In the future, don't bother looking for answers from
me.
>> Your search is _already_ broken, it's just that you hadn't noticed it
>> until now. The Network Address attribute is what they call a
>> "structured" attribute containing multiple parts. The first, as you've
>> noticed, is a network type (1 = IP, 9 = TCP), which specifies the format
>> of the remaining data in the attribute. You're only looking for IP,
>> which is fundamentally wrong as the connection type could be IP, IPX,
>> TCP, SNA, etc. here.
>We neither use SNA or IPX on our network (I'd be surprised in this day and
>age if anyone still did).
Yes, but the point isn't what you're using. The point is that what
Novell expects to be able to put there includes the network type. You
can't blindly assume that the network type will be IP. Even if current
implimentations of Client32 connecting to NetWare servers _always_ put
IP there, the next revision of Client32, or the next revision of
NetWare, could very well switch to using TCP. At that point your
perfectly working code with its invalid assumption is going to go
*sproing* and stop working. And, it looks to me like you'll be blaming
Novell for breaking your code, when, in fact, your code was broken from
the begining, you just got lucky that it was working.
>> Once you have the network type, then you can parse the remaining parts
>> of the structure.
>I think you are not understanding the nature of the problem: I am well
>aware that I can parse the networkAddress attribute out of eDirectory into
>its constituent components, that is trivial. But that is not what I am
>trying to do: I am trying to search (over LDAP) for an entry that has a
>certain IP address which is quite different.
I understand exactly what you want to do. At this time, it's not
possible to do that. I don't know if that's a limitation of the LDAP
protocol specs (handling wildcards in the search filter), or a
limitation of Novell's implimentation of the LDAP specs in eDir. At this
point, I don't care to bother to look it up for you, or try to figure it
out. What was possibly an interesting problem to be looked in to has
just become, for me, a waste of my time.
>Rant:-
>On a separate note, your overall response is a typical one that a poster
>receives on the forums. Novell bigots tend to be very condescending and
>dismissive of most of the posts made. It is almost as though a Novell
>bigot cannot bear to hear anything negative about Novell software and will
>consequently close their mind to the question being asked and then attempt
>to pour disdainful scorn on the poster.
You have no idea what you're talking about. I do not see, anywhere in my
post, where I was being biggotted, condescending, or dismissive. I tried
to help you. You were looking for help. If you don't like the help you
got, that's not the fault of the person trying to help you. Learn to ask
better questions.
I don't work for Novell. I have no control over how Novell choose to
develop their software, nor what standards or features they impliment. I
thought I could help you understand that the assumption you were making
was invalid and likely to cause you problems in the future, as well as
understanding how you will probably have to do what you're trying to do
in order for it to work reliably. You seem to have taken offense at
this. That's your problem, not mine.
>inadequate code. I am thinking my resolution to this issue will probably
>involve me populating a MySQL database with user's networkAddress
>attributes using IDM. Then I will be able to use a perl script to query
>the database and authenticate the user from that.
That'd probably work, yes.
> I am not an idiot as your
>reply seems to indicate and you clearly haven't fully understood the
>question I was asking.
I didn't think, or imply, that you're an idiot. I did fully understand
what you are trying to do, and your question. Given your rant, I've
changed my opinion of you, but not for the better.
>Your response is the kind of response that
>continues to convince me that these forums are usually a waste of time
>because the dialogues that occur are so superficial and misinformed.
Funny that. I have exactly the opposite opinion, and experience.
"Have a nice day..."
David Gersic
is multi-valued, and buggy, so that searching for a particular value may
get you some user object that logged in to that workstation last year,
but still has the Network Address value stuck on their object. *That*
should be an entertaining rant...
Simon Tideswell
I don't wish to pursue this argument indefinitely and I am quite happy for
you to have the last word. You certainly seem to be going after me about
this - the boot is now definitely on the other foot!
I think your point about the Network Address being "buggy" is probably
well-founded - isn't this all the more reason to be critical of Novell and
try and get them to raise their game? I give this type of feedback to
Novell via other means frequently. You'd hope (if Novell have any
sense at all) that they'd monitor these forums to see what the hot issues
are and what sort of regard they are held in by IT professionals. That's
why I can appear to be negative about Novell/Novell-bigots on the forums,
it might be going into /dev/null but one can only try?
In regard to the resolution, I have written some DirXML policy to pump the
Network Address attributes into a PostgresSQL database. This is then
replicated around the network to other instances of Postgres using Slony.
Too bad if you don't have DirXML/IDM I don't know how you would resolve
this issue. If anyone wants information on how to do this (it's quite
involved: requires XSLT, a small Java class, modifying Postgres SQL
triggers/rules and installing Slony from source) please contact me
directly.
I'm sure we'll meet on the forums again, David, I look forward to it! The
last word is yours if you wish to take it.
Simon
Jim Willeke
So if it is UDP or TCP is it not for all of our practical purposes also IP?
A little more on this from my testing.
Logged into SUSE Linux Enterprise Server 10 (i586) server with the
Novell Client.
The value for the network address comes back as:
9#05-E1-C0-A8-01-79
Where is the format for TCP defined? It appears to be two octets for the
port followed by the IP address, but I do not see this documented anywhere.
The C0-A8-01-79 is the IP address what is the 05-E1 (5-225)?
If it is looked as 05E1 it is 1505.
The ndstrace -c connections provides:
tcp:192.168.1.121:1504 .jim.butler.people.willeke.com
tcp:192.168.1.121:1505 .jim.butler.people.willeke.com
iMonitor only shows:
Present TCP 6 192.168.1.121:1505
-jim
Jim Willeke
What version of OES are you using?
-jim
Simon Tideswell
> What version of OES are you using?
> -jim
Hi Jim, I originally installed from the OES SP2 CD's. Since then the box
has been pretty much kept up to date through the Red Carpet channel.
Simon
Simon Tideswell
> that would provide the user that is connected on that IP address.
> At BEST you would have to return ALL the networkaddress in the tree and
> then parse the result set.
>
> I am pretty sure you can not perform a substring match on a binary
> attribute. I get:
> Search failed Root error: [LDAP: error code 18 - Inappropriate Matching]
> when using (networkAddress=9#*)
> Or
> (networkAddress=/39/23/*)
>
> Kind of makes the networkaddress attribute worthless, doesn't it?
> -jim
Doh!!!!! I had been trying to show more grace in my follow-up posts but
you just got me!!!! Yes I couldn't agree more, a real retrograde step in
my humble opinion. You ought to take care in venturing to suggest that
Novell may have got it wrong, though, as you'll leave yourself open to the
derision of the "Novell Bigots" and you'll never get them to admit that
Novell is at fault, they'll just wriggle around proving what an idiot you
are before admitting there is a problem that needs fixing. Shame on me!!!!
Simon Tideswell
> port followed by the IP address, but I do not see this documented anywhere.
Solutions article about using Perl's Net::LDAP to pull Network Address
information out of eDirectory that mentions some aspects of this.
> The ndstrace -c connections provides: tcp:192.168.1.121:1504
> .jim.butler.people.willeke.com tcp:192.168.1.121:1505
> .jim.butler.people.willeke.com
David Gersic
<stid...@networkten.com.au> wrote:
>I don't wish to pursue this argument indefinitely and I am quite happy for
>you to have the last word. You certainly seem to be going after me about
>this - the boot is now definitely on the other foot!
I'll let it die here as well. I bear you no ill-will.
>I think your point about the Network Address being "buggy" is probably
>well-founded - isn't this all the more reason to be critical of Novell and
>try and get them to raise their game?
I don't disagree. I wasn't, and am not, attempting to offer any
commentary here on Novell. I was only trying to impress on you that your
assumptions, and your code based on those assumptions, are likely to run
in to trouble based on what I know of how this attribute is used and how
it works. You can take or ignore my advice, that's up to you.
If I were commenting on Novell or their products or bugs therein, that'd
be a different story.
If you get a chance to talk to anybody in Support for eDir, or the PM
for eDirectory, and you mention my name and "network address" in the
same sentence, you'd best be prepared to duck. I'm somewhat well known
for my views and outspokenness on the subject.
>In regard to the resolution, I have written some DirXML policy to pump the
>Network Address attributes into a PostgresSQL database. This is then
>replicated around the network to other instances of Postgres using Slony.
Cool. Sounds interesting. How do you handle the situation where the user
logs out and the Network Address is not deleted? Are you timing them out
somehow in your database? If so, that could be really interesting, but
probably more relevant in the IDM support newsgroup than here. It also
gives me an interesting idea...
>Too bad if you don't have DirXML/IDM I don't know how you would resolve
>this issue.
I've got lots of IDM here. There are about 25-30 eDir drivers, 2 MAD
drivers, 14 GW drivers, 2 PeopleSoft drivers, a couple of dozen
Loopback, and now some DelimText drivers in my life.
>If anyone wants information on how to do this (it's quite
>involved: requires XSLT, a small Java class, modifying Postgres SQL
>triggers/rules and installing Slony from source) please contact me
>directly.
Really? What's it need all that for?
David Gersic
wrote:
>First, I though UDP and TCP were higher level protocols that ride on IP.
They are. I suspect where Novell are using "IP", they really mean "UDP".
But that's a whole 'nother argument I guess.
>The value for the network address comes back as:
>9#05-E1-C0-A8-01-79
>
>Where is the format for TCP defined?
It'd be somewhere in the Developper documentation, if it's anywhere. I
haven't gone looking for it.
Jim Willeke
David Gersic wrote:
> On Wed, 20 Dec 2006 21:29:57 GMT, Simon Tideswell
> <stid...@networkten.com.au> wrote:
>
>> The question relates to the difference between the way the user's
>> NetworkAddress attribute is registered in eDirectory in OES Linux and
>> NetWare: if the user's server is OES Linux the NetworkAddress (when
>> viewed in ConsoleOne) ends up being something like TCP: 10.20.4.15,
>> whereas if the user's server is NetWare the NetworkAddress would be IP:
>> 10.20.4.15.
>
> Your search is _already_ broken, it's just that you hadn't noticed it
> until now. The Network Address attribute is what they call a
> "structured" attribute containing multiple parts. The first, as you've
> noticed, is a network type (1 = IP, 9 = TCP), which specifies the format
> of the remaining data in the attribute. You're only looking for IP,
> which is fundamentally wrong as the connection type could be IP, IPX,
> TCP, SNA, etc. here.
So does this not imply that provided an IP address, there is no Search
that would provide the user that is connected on that IP address.
At BEST you would have to return ALL the networkaddress in the tree and
then parse the result set.
I am pretty sure you can not perform a substring match on a binary
attribute. I get:
Search failed Root error: [LDAP: error code 18 - Inappropriate Matching]
when using (networkAddress=9#*)
Or
(networkAddress=/39/23/*)
Kind of makes the networkaddress attribute worthless, doesn't it?
-jim
>
David Gersic
wrote:
>So does this not imply that provided an IP address, there is no Search
>that would provide the user that is connected on that IP address.
I would argue that this is the case, yes.
I can log in as user "bob" from address 10.0.0.1, and disconnect my
machine from the network. I can connect a new machine, set for IP
address 10.0.0.1, and log in as user "fred". Now both "bob" and "fred"
have Network Address values (ignore the protocol and port for now) of
10.0.0.1.
Watchdog will eventually notice that "bob" hasn't done anything in a
while, and will ping 10.0.0.1, and will get an answer, so "bob" will be
left alone.
Even if you can search for "10.0.0.1", at best what you're going to get
is "bob" and "fred" are both logged in using that address.
More interestingly, if you're (like the OP) doing a Squid proxy based on
this information, you see "bob" log in. "Fred" goes to hit the Squid
proxy, which duly notes that "bob" is logged in, and lets "fred" use the
internet because "bob" is logged in. Oops.
>At BEST you would have to return ALL the networkaddress in the tree and
>then parse the result set.
Right. And, as noted above, even that's not all that great an answer.
>Kind of makes the networkaddress attribute worthless, doesn't it?
IMHO, yes. It is. As far as I can tell, the only official purpose that
Network Address is intended to serve is so that the concurrent
connection restriction feature has something to count as "connections".
Anything else that it might be seen as useful for may or may not work
very well. And, as I've rambled on about before, due to the *way* it
works, and the ways that it doesn't work, even this use of it is not
what I would call reliable.
Jim Willeke
-jim
Andrew C Taubman
Novell may have got it wrong, though, as you'll leave yourself open to
the derision of the "Novell Bigots" and you'll never get them to admit
that Novell is at fault, they'll just wriggle around proving what an
idiot you are before admitting there is a problem that needs fixing.
Novell like any other software provider makes mistakes and there are
bugs in their code all the time. I and the others here have no problem
admitting that (when it's true), and deal with the consequences every
day, both here and in my day job. Novell have no problem admitting that,
which is why they release patches almost every day to fix those bugs. We
frequently report bugs to Novell direct from these forums and our own
testing and get them fixed.
The IP address situation situation you are complaining about is not a
bug. eDir correctly records that the network address is IP or TCP as
appropriate. As David has said, the issue is in your utility design that
assumed the address would always be IP. You've tried to blame the sysops
here, the non-sysop regulars, and now Novell, but the issue you've come
across is none of their faults on this occasion.
I'm still not understanding what you ever wanted Novell or us to do
about your situation; as I said before the only possibilities seemed to
be to stop recording the protocol at all, or change eDir on Linux to use
IP not TCP. If all you wanted was advice on how to redo your utility to
work around the situation, fine, but when David attempted to do exactly
that (correctly pointing out the problem was in the incorrect assumption
in your utility) you went off your brain at him and us.
To then (incorrectly) claim Novell or the Sysops here are reluctant to
admit bugs in their code when you yourself are doing precisely that is
simply amazing.
Jim Willeke
NT_UDP 8 User Datagram Protocol (UDP) address
http://developer.novell.com/documentation/ndslib/index.html?page=/documentation/ndslib/nds__enu/data/hniuyp90.html#hniuyp90
And As near as I know, any documentation that exist for this should be here:
http://developer.novell.com/documentation/ndslib/index.html?page=/documentation/ndslib/nds__enu/data/h2y7hdit.html
And none of them define what the format of the "Address" part of
networkaddress is.
Other than this that only shows the NDS structure and it only defines
the expected length for IPX and IP.
http://developer.novell.com/documentation/ndslib/index.html?page=/documentation/ndslib/nds__enu/data/sdk2855.html
-jim
Simon Tideswell
> Novell like any other software provider makes mistakes and there are
> bugs in their code all the time.
I actually think Novell is NOT like any other software provider: the
large amount of bugs, the frequent criticality of the bugs and the slow
fix rate of the bugs mark Novell out for special mention. This is not just
me speaking: this is the opinion of end-users, third-party vendors,
resellers - pretty much anyone with an opinion will have a negative
opinion of Novell product quality.
> The IP address situation situation you are complaining about is not a
> bug.
I agree and have said that previously in this thread. However isn't
it somewhat irritating to store a potentially useful attribute in
eDirectory in a way that it cannot be searched for properly (especially
when hitherto a search was possible)? This makes eDirectory less useful
and flexible for other applications that might want to leverage
eDirectory? The 'application' I'm using is Perl Net::LDAP which is open
and flexible and a pleasure to use, kludging things in order to make it
work with eDirectory is a pain. Up until now Net::LDAP has worked with
eDirectory and some scripts that make reasonable assumptions about the
network address very well, I hadn't coded for TCP _AND_ IP in my script
precisely because of the difficulty with wildcard substring matches
for TCP that this issue is about but were it not for that single
limitation I could have coded any number of address types.
> As David has said, the issue is in your utility design that
> assumed the address would always be IP.
But Andrew it _WAS_ always IP - this has been working extremely well in
production for 1000+ users for approximately 18 months now. I'm not a
software developer - I am a sysadmin. As such when I write code I'm not
going to bust my chops to write the most fantastic robust code, I'm going
to write something "quick and dirty" that works. I'll leave the fancy
stuff to the software vendors. Making life easy for sysadmin hackers like
me by making the product work smart and do things the way any right-minded
person would expect is good for customer satisfaction and makes the
product more useful to the sysadmin - changing things adversely undermines
all of that.
> You've tried to blame the sysops
> here, the non-sysop regulars,
No I didn't, I may have ranted but I haven't blamed anyone on the forum
for the issue, read back if you don't believe me
> and now Novell,
Yeah I blame them alright, Novell software is making my life a misery
right now. I have so many SR's open and so many bugs that I don't know
what to work on next.
> I'm still not understanding what you ever wanted Novell or us to do
> about your situation; as I said before the only possibilities seemed to
> be to stop recording the protocol at all, or change eDir on Linux to use
> IP not TCP.
I was looking for clarification that my assumption about changes in OES
Linux were correct. I also hoped someone might know how to wild-card
search on the network address. I also hoped Novell might take on board
that they have made another foul-up from a customer's perspective. Maybe
even to convince them to record IP _AND_ TCP or record network addressin a
separate searchable attribute, I'm not fussy I can work with almost any
scenario as long as it doesn't go way outside my limited skills.
> If all you wanted was advice on how to redo your utility to
> work around the situation, fine, but when David attempted to do exactly
> that (correctly pointing out the problem was in the incorrect assumption
> in your utility) you went off your brain at him and us.
When David replied I read his message as saying 'you're code is flawed'
and recounting a lot of information I already knew (I'd have to know
it to have written the scripts in the first place). The code may be flawed
in the sense that it has _potential_ holes in it, but in production with
all (99% of) my user's happily registering their IP's in eDirectory all of
this has been working extremely well. If you have something working in
production and know it to work very well and someone says "that's rubbish
- it's not working" how would you react?
> To then (incorrectly) claim Novell or the Sysops here are reluctant to
> admit bugs in their code when you yourself are doing precisely that is
> simply amazing.
I'm a sysadmin hacker as I said above, rest-assured my code has lots of
bugs, at least initially (though I'm actually pretty reasonable)- but I
don't believe the standards of my code need to be up to the standards of a
software vendor who is charging money (and lots of it) for their code. As
a dabbler in programming (scripting would be more accurate) I have some
insight, which is why I'm so incredulous that Novell gets it wrong so much
of the time. By all means say my code has got bugs, I don't deny it but if
Novell had more accomplished and flexible products I wouldn't need to
inflict my buggy, ill-conceived code on the world. As someone who has
opened possibly 10 SR's last year and probably 8 of them turned out to be
product defects I know the process of getting defect accepted by Novell
can be quite time-consuming and frustrating. After you get the defect
accepted then you will doubtless wait a VERY long time indeed for code
that resolves the issue to be released. You will quite probably have to
apply patches a number of times to resolve the issue as the initial
patches won't resolve the issue or will contain new defects. Bugs are a
fact of life and sysadmins just have to deal with them - it's our job. But
when the bugs become overwhelming in number then that's going to make even
the most placid of individuals arch up in irritation. Ultimately I would
like to reach a point where I have nothing to whine about and the product
simply works as designed/desired but Novell are a long way off of that.
Perhaps I rant like I do because I feel that if enough people are ranting
then Novell will say "Mmmmmm the masses are not happy - maybe we should
change our processes, maybe we should hire more developers, maybe we
should survey what customers want and don't want a little more?"
This issue is resolvable, in fact I've nearly completed this. This issue
is minor also, but this issue comes on the back of a massive number of
issues I've had recently with product QA (especially GroupWise). I didn't
really have the time to develop a new squid authentication mechanism, I've
got so much other stuff to do. That's why I went off like a sobbing little
girl back whenever it was. Andrew, you don't get it - I don't think you
ever will. Just get back to day-dreaming about how Novell will own 75% of
the NOS market share again and Microsoft won't be stripping customers
from Novell faster than a speeding bullet anymore, I'm sure that will
happen if you continue to ignore customer concerns and keep churning
out bugs with the odd line of good code included.
Enough already I'll meet you in another topic I'm sure.
Jim Willeke
I am an old guy in this business and grew up on things like HDOS and CPM.
I have been a CNE since 1989 and have worked with Novel and Microsoft
from their beginnings.
Every software company has their faults. But, I have found Novell's
software to be consistently the best architected and most poorly
marketed software on the market.
If you want to bash Novell, call your local Novell Rep he will be happy
to point you to the RIGHT people that can talk to you about your concerns.
As a courtesy to the volunteers, employees of Novell and guests in this
forum which have little or no power to deal with the things you are
bashing, don't bash Novell here.
Have you ever gone to a Linux forum or a Microsoft forum and bash their
products? I am quite sure you will get the same kind of "bigot" response.
I really appreciate the technical information you provided and I am
facing very similar dilemma with the networkaddress attribute that you
are. But, in the broad spectrum of "normal" users of eDirectory the
networkaddress issues is limited to a very few number of people.
Again thanks for your technical input.
-jim
Kevin
Hopefully the heat will now have gone out of this argument!
I followed Simon’s original Cool Solution article – Seamless
Authentication with the Squid Proxy and thought this is just what I
need.
I’ve also fallen foul of the differences between the Netware/OES use of
the Network Address attribute and sent a lot of time trying different
combinations of IP address before reading these posts.
Can someone please tell me….
Is there another way of searching for the address using wildcards so
the port number can be masked out? (We only have 60 users, but it does
not seem sensible to retrieve all the network addresses and trawl
through them).
If so, this is a sensible way to provide the seamless authentication
that Simon was trying to achieve? (I read the comments regarding the
possibility of duplication addresses)
Is there a better way to provide to achieve this link with Squid?
Regards,
Kevin Gutteridge.
--
Kevin
Simon Tideswell
It's alright - I've had a couple of chill pills!
> Is there another way of searching for the address using wildcards so
> the port number can be masked out? (We only have 60 users, but it does
> not seem sensible to retrieve all the network addresses and trawl
> through them).
I don't believe it can be done through LDAP searches and, e.g., perl
scripts but maybe some eDirectory native API? This of course will be a
substantially harder thing to code and get working. As you do
only have 60 users you _could_ continually poll eDirectory (every few
minutes) to get ALL addresses and then put them in a flat file or
file-based DB (e.g. Berkely) and let your script use this for
authentication, really ugly but it should work.
> If so, this is a sensible way to provide the seamless authentication
> that Simon was trying to achieve?
I am using IDM to populate a Postgres SQL database now with the IP
addresses. As I have 1000+ users I can't really be continually polling
eDirectory for all the addresses so IDM works well for me. This was a lot
harder than what I posted on Cool Solutions: with XSLT, Java, SQL and Perl
all required to get it working. However despite the difficulty of setting
it up it does appear to be working very well. If you use IDM (which is a
superb product) with the JDBC driver already you could do something
similar.
> (I read the comments regarding the
> possibility of duplication addresses)
I have found, despite the comments of the other posters, that the
Network Address is _quite_ reliable and if an end-user's address is not in
eDirectory then either they should have their Novell client reinstalled or
they have been logged on for days and days and need to reboot.
> Is there a better way to provide to achieve this link with Squid?
One thing I considered but have not looked into is setting up eDirectory
to be a SAMBA domain controller. Then I think, in theory, you could use
Squid's NTLM authentication method to authenticate users against
eDirectory as though it were a Windows server. I suspect that you might
need to add each PC to this SAMBA domain so it might not be practical -
don't know enough about NTLM to know if I'm correct about that though.
Simon
Samuel Moffatt
I've had a similar set up as Simon with single login authentication
using this attribute and found out a while ago the same issue he's
been having with TCP addresses which is annoying but none the less. I
wasn't aware of what was causing the issues because I'm the other side
of the fence, applications developer, and don't usually follow the
server systems that don't explicitly relate to me. When I started the
integration project using this over a year ago I was assured by our
Novell admin that this attributes was perfectly safe and updates
almost instantaneously with our system so it should protect us. We use
IP based authentication for our proxy using a small application that
runs on boot so concerns about IP spoofing weren't that great (since
there are other things hanging off this). I just have a few things I'd
like to get clear.
1) networkAddress, being a binary field, is unsearchable under the
current eDirectory LDAP system. This appears to be the core issue
because if we could search on it, this discussion wouldn't be taking
place. Is Novell planning on providing the ability to search this
field at any point in the future? (I'm assuming this is the issue
behind the 'inappropriate matching' error, please correct me if I'm
wrong)
2) On the comment about the field being structured data, I understand
that it is structured, just like an email address is also a structured
field. Difference being is that it is easy to search on the email
attribute, we cannot. Structured or unstructured if you only have half
the information and you can't use some form of wildcard search then
you're up the creek.
3) In a mostly controlled environment I'd say making the assumption
that the field values will behave a certain way is pretty safe. Like
most things this is a case where not everything is tested 100% before
deployment because we forget about them (because they work so well).
We were in the same position and its only now when our few OES boxes
are being used (it was in fact the network guy who pointed out things
weren't working for him) that the bug has been discovered. Like
anything that you depend on, if someone else has control and changes
the way it acts and breaks your previous assumptions there is nothing
you can do about it. I don't think anyone can claim innocence from not
making an assumption and later having it either proven wrong or the
circumstances around it changed and it becoming wrong.
In any case we're about to deploy IDM3 so I'll add this to our list of
things to include when we move this way. It would be nice if this kind
of a work around wasn't required. Thanks all for the information, I
now know the answer to a long term question of mine :)
Sam
On Jan 23, 2:22 pm, Simon Tideswell <stide...@networkten.com.au>
wrote:
Jim Henderson
> 2) On the comment about the field being structured data, I understand that
> it is structured, just like an email address is also a structured field.
> Difference being is that it is easy to search on the email attribute, we
> cannot. Structured or unstructured if you only have half the information
> and you can't use some form of wildcard search then you're up the creek.
It's not structured in the way that e-mail is structured - the comment
about it being a structured field means that it's a complex data type
represented as a series of bytes where the structure depends on values of
other fields.
e-mail address is represented as a string - there's no structure, you can
put in a valid e-mail address ("us...@domain.com") or a bogus value
("thisisnotanemailaddress"), and the directory doesn't care.
Network Address is a data type in eDir. There are fields that determine
the data types at the application level (not the directory level - it
doesn't know; just look at predicate data - which is represented with a
"network address" data type, even though it isn't).
One of the principles of writing software is to understand external data
types and their uses, without assumption. The Network Address data
structure is documented in the SDK for C documentation:
typedef struct
{
nuint32 addressType ;
nuint32 addressLength ;
pnuint8 address ;
} Net_Address_T;
That should tell you right away that the value of the address is variable
length, and the raw data representation will likewise be a variable
length; pnuint8 is a pointer data type. In C terms, you have to malloc()
the storage space based on the address type and length values.
In LDAP terms, what you end up with is a value that has to be decoded
before it can be parsed - and the decoding depends entirely on the values
within the addressType and addressLength fields.
Wildcard searches are unlikely to be implemented because they would depend
entirely on the server side knowing how to parse the address field, which
would mean adding code to the core to parse every possible address type
that could be populated into the data type and determining the proper
values for the address field. In terms of search performance, this would
be fairly expensive, which is why the server side doesn't know about the
specifics of the data that fits into the structure. Currently, there are
15 types of network address supported (types 0-14), but that could change,
and I know the type field is used in other ways for different types of
data that's similar in structure - such as the predicate statistics data.
Jim
--
Jim Henderson, CNA6, CDE, CNI, LPIC-1
Novell Training Services
Kevin
Since my last post I have had some further thoughts on the issue…..
What I intend to do (and have started by downloading the Novell
LDAPSDK), is code a version of ldapsearch that I can stitch onto
Simon’s Squid configuration to replace the PERL section.
Retrieve all the Network Address attributes for the user records into a
sorted list and locate the IP address passed by Squid. In my list if
the Network Address is unique then this will be a pass and the user
name given back to Squid, otherwise (in the case of the directory not
being updated yet and a duplicate existing), this will count as a fail
and Squid will fallback to the user authentication login prompt.
In my circumstances, we only have 60 users, so I assume this operation
will be almost instantaneous.
I’m currently reading the manual section on authentication techniques
(interesting stuff!).
Does anything think there is a floor in this approach?
--
Kevin
Jim Willeke
then you can perform a search for given IP Address.
Why would the same attribute be populated differently on different
platforms? This seems like a purely arbitrary decision.
The packet type did not change. Actually they are both TCP packets which
implies they are both IP packets.
Also some further information on these issues:
http://www.willeke.com:9080/wikildap/Wiki.jsp?page=NetworkaddressAnomalies
-jim
David Gersic
wrote:
>Why would the same attribute be populated differently on different
>platforms? This seems like a purely arbitrary decision.
Agreed. We don't know why. Maybe it makes sense, maybe it doesn't.
David Gersic
wrote:
>1) networkAddress, being a binary field, is unsearchable under the
>current eDirectory LDAP system.
It's not just a binary field. It's a structured attribute. It's exposed
in the LDAP interface as an encoded field, since LDAP doesn't have any
other good way to represent this sort of data.
>This appears to be the core issue
>because if we could search on it, this discussion wouldn't be taking
>place.
You can search for it, sort of, but not the way the other poster wanted
to. I'm not sure where that limitation is, and I don't feel like
researching it right now. You might grab the relevant RFCs for LDAP and
start reading, though, if you really want to find out. I suspect it's a
limitation in LDAP's specification.
>3) In a mostly controlled environment I'd say making the assumption
>that the field values will behave a certain way is pretty safe.
Making any assumption assumes that you know what you're depending on,
and that you understand that there may be some squishy bits revealed
later if your assumption didn't take something important in to account.
If you're a programmer, then something like:
char *p;
p=malloc(1200);
strcpy(p,"here's a string for you");
_MAY_ always work for you, but the underlying assumption (that malloc()
will always manage to grab you a hunk of memory) may also eventually
come around to bite you in the a**. The fault, there, is then not one of
malloc(), but one of the programmer that didn't check it's return
pointer to make sure it was valid before using it.
>weren't working for him) that the bug has been discovered. Like
>anything that you depend on, if someone else has control and changes
>the way it acts and breaks your previous assumptions there is nothing
>you can do about it.
That's true. But, since this has changed *several* times so far, I'm
comfortable with my assumptions that it will likely change again, and
that blindly assuming that it'll always work the way it did for NetWare
only trees is probably not a good idea.
>I don't think anyone can claim innocence from not
>making an assumption and later having it either proven wrong or the
>circumstances around it changed and it becoming wrong.
That's certainly true, yes.
David Gersic
<Kevin....@no-mx.nds_engineer.com> wrote:
>Does anything think there is a floor in this approach?
The only flaw I can think of is what will you do when your search
returns a single user with multiple Network Address values, some of
which may be unique, and some of which may be the same as other users'
values?
Jim Henderson
the inconsistency in the network address attribute being cleaned up or
populated properly. There have been various issues with this through the
years, with it sometimes working and sometimes not.
That means from a security standpoint, if you use the network address as a
means of restricting access to the 'net, you will run the risk of people
being able to access it when they shouldn't be allowed to.
In my personal opinion, users should be used to filling in a name and
password on either a web form or a pop-up password dialog box by now when
they surf the 'net. This problem is easily resolved by utilizing a group
membership and taking 10 minutes to train the users on the change before
it is put in place. You may have questions asked of your help desk for a
couple of days while the 'slow' users figure out the new system, but after
that, it should become second nature to them.
Jim Willeke
with 10 other users?
Or I suppose if it was Linux and there were many users logged in from
Novell clients.
They all have the same IP address.
And the first one in gets through and then the other users get in cause
Squid sees an IP address with a valid session?
Ah ha. Now we have the reason for the Net Type TCP with a port address.
Each user would be connected on a different port to the Server so each
user would be distinguishable from the other.
Now, how can we make it searchable?
-jim
Samuel Moffatt
> Each user would be connected on a different port to the Server so each
> user would be distinguishable from the other.
>
> Now, how can we make it searchable?
If we know what we are looking for (e.g. both TCP address and IP
address) we can search for say 9#43017219531 (a number I pulled from
one of our entries) because we know both the IP address and the port
that the eDir connection is on. But if we're going to do this in a web
environment, we need the browser to send us this piece of information
(since we already get the IP address) to search for them. We can find
things if we know all the answers, but if we don't know the answer we
need a wildcard and this is where things fall over again.
As an aside I pulled the network cable out of a logged in box and used
another box (that I just plugged in with the same IP address) to log
into Novell. The networkAddress didn't get replicated across to the
new box's user but remained on the other account for a while so that
anything relying on this would be determined to be the original user.
I think sucking it out and storing the field in a database is the
solution I'm going to head towards...its either that or fight with MSAD
+Kerberos.
Sam
On Feb 16, 4:02 am, Jim Willeke <j...@DOT.willeke.com> wrote:
> As a side note... what do you do if the user is on a Citrix type machine
> with 10 other users?
>
> Or I suppose if it was Linux and there were many users logged in from
> Novell clients.
>
> They all have the same IP address.
>
> And the first one in gets through and then the other users get in cause
> Squid sees an IP address with a valid session?
>
> Ah ha. Now we have the reason for the Net Type TCP with a port address.
> Each user would be connected on a different port to the Server so each
> user would be distinguishable from the other.
>
> Now, how can we make it searchable?
>
> -jim
>
> Kevin wrote:
> > Since my last post I have had some further thoughts on the issue.....
Jim Henderson
> its either that or fight with MSAD +Kerberos.
You know, there is a Kerberos server for eDir as well....
Kevin
Since my last post on this in February (how time flies.....), I've been
busy with other stuff, however this has been a thorn in my side. We are
migrating various system to OES and my users are currently used to
using Microsoft Proxy Server. They are already logged into the network,
run their browser, surf and actions are logged. It seems backward to
ask them to log in again, but I require the web logs with their details
for auditing.
I’ve taken Simon’s original approach and written a replacement for his
perl script in C that makes a LDAP connection, retrieves the userDN
based on the IP address and will only allow connection if that
address/userDN combination is deemed unique. It then goes on to perform
the checks based on group membership.
If connection fails then the Simon’s original technique of dropping
back to a normal LDAP login is performed. So it attempts to be seamless
but allow a catch all.
In testing so far it seems to be working OK with no obvious delay
detected. If anyone is interested then let me know and I will make the
source available.
Regards,
Kevin.
--
Kevin