Re: AFP and universal password problem

[Marcel Cox]

Did it work before applying the password policy? If yes, were you using
simple password, or did you use the cleartext option? In the case you
might have been using the cleartext option, did you remove that option
after switching to universal password?
In any case, as a first debugging step, you might want to take an NMAS
server trace like descibed here:

http://www.novell.com/support/viewContent.do?externalId=3815371

then post the resulting trace for a failed login here.

--
Marcel Cox
http://support.novell.com/forums
------------------------------------------------------------------------
Marcel Cox's Profile: http://forums.novell.com/member.php?userid=8

[Massimo Rosen]

Hi,

bkuhlmann wrote:
>
> Oh, sorry for not responding so long but I opened a call with Novell on
> this but they are not very responsive so i retreated back to this
> forum.

Well, to answer yor questions properly, it would be helpful to know your
current OS, Service Pack, and eDirectory version.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de

[Marcel Cox]

bkuhlmann wrote:

>11: ERROR: -1688 Maximum allowed connections 1 exceeded.
>11: ERROR: -1688 Login Restrictions

Well, the message is very clear: The user has a concurrent cnnection limit
and he has exceeded that limit.

[Marcel Cox]

bkuhlmann wrote:

>Well, but should not the novell client where the account is already
>logged in transfer the credentials to the iprint client without the need
>for a further connection?
>And why does this behaviour occur after deployment of UP (policy
>assignments were deleted after that but the issue persists)?
>And before that everything worked well?

I'm a bit confused here. I thought this thread was about AFP not working.
Now however you are talking about Novell client and iPrint.

Anyway, the only place where the login "state" was shared among different
services was between the Novell client and NDPS. For most other Novell
services, you may have the same user and password in different services
and that login screen might even capture the userid and password
information to automatically use it for different services, for the
backend hwoever these are individual connections that count separately.
Now how concurrent connections behave in multiple protocol environments
depends on many factors:
- the host OS. On NetWare, at least for NCP connections, Novell used to
only record the IP address for the connection in eDirectory, and the
concurrent login enforcement was based on the number of different IP
addresses used. So when different connections were used, but all come from
the same IP address, they would count as one.
Now for eDirectory on Linux, this is unfortunately different. On Linux,
Novell made the bad decision to not only record the IP address, but also
the source port number for connections. This means that different
connections from the same machine now count as multiple connections. This
also reintroduces the concurrent connection problem that Novell had at
some point in time with the IPX protocolwhich also recorded tge port
number together with the address.
- the way Novell has implemented a service can also make a big different
on concurrent connection behaviour. In fact, depending on how Novell
implemented authentication for the protocol on the server side, for
eDriectory, the connection may seem to come from the server address and
not from a workstation address. As such, such connections may count extra.
- for OES2/Linux, some services like Samba, CIFS and AFP do not
authenticate the users against eDirectory. Instead, the corresponding
services reads the user's password from eDirectory and handles the
autheitcation itself. For such services, user connections restrictions
don't count at all against eDirectory limitations unless the service
implements the restrictions within the service.

Now it's possible that your problem is not really caused by universal
password itself, but just by the presense of Linux based eDirectory
servers in your tree and that authentication may somehow "touch" these
Linux servers. In any case, the way Novell implemented the recording of
addresses in eDirectory on Linux makes it near impossible to realibly
implement concurrent connection limitations in multi server or multi
protocol environments. You may be forced to relax the concurrent
connection limitations to keep your environment working and your users
able to continue to login correctly.