Conference irocz::netrider

Hello Guys.

I am only getting time now to look at this dial back again. 

Someone mentioned dnas 2.2 as the fix for my WIN95 dial back problem. However the supplied work 
around (&c0 s0=1) will not work in my case as I am not even getting as far as getting properly 
authenticated when I use the call back option for the users account. That makes me think I am 
doing something else wrong.

In summary:

I have WIN95 users dialing in PPP and being authenticated by the servers realm account d/b. That 
side works fine.

However as soon as I take one of these working accounts and modify it for "mandatory call back"
I get user authentication failure as follows from a WIN95 client: 


Local>
Event: Login                                     Time:  87 20:45:38
   Port: 7            Access:  Dynamic
   Username:
Event: Session Connect Attempt                   Time:  87 20:45:38
   Port: 7     Sessid: 1       Protocol: PPP     Access: Local
   Username:
   Peer: RESV_DSERVICE
Local>
Event: Login                                     Time:  87 20:45:39
   Port: 7            Access:  Dynamic
   Username: testacb@belfast
Event: Dial Request Failure                      Time:  87 20:45:39
 Port: 7        Mode: Unknown    Service:
 Username: testacb@belfast
 Reason: Authorization failure (dialback mode)
Event: Session Disconnect                        Time:  87 20:45:39
   Port: 7    Sessid: 1        Protocol: PPP
   Reason: Normal  TX: 181 bytes    RX: 184 bytes
   Username: testacb                    
Event: Logout                                    Time:  87 20:45:39
   Port: 7    TX: 181 bytes    RX: 184 bytes
   Username: testacb@belfast


Port seven on the server is configured for "dial back" so I presume that is why the peer changes 
to "RESV_DSERVICE". When the same user is used on a port not configured for "dial back" the same 
error results.

However if I edit the user account on the DS90M and remove "mandatory call back" the account 
authenticates and works ok regardless of the port.

Local>
Event: Login                                     Time:  87 20:51:00
   Port: 7            Access:  Dynamic
   Username:
Event: Session Connect Attempt                   Time:  87 20:51:00
   Port: 7     Sessid: 1       Protocol: PPP     Access: Local
   Username:
   Peer: RESV_DSERVICE
Local>
Event: Login                                     Time:  87 20:51:01
   Port: 7            Access:  Dynamic
   Username: testacb@belfast
Local>
Event: IP Address Set                            Time:  87 20:51:04
 Port: 7         Address:   16.183.112.107
Local>

I know that dnas 2.0, which I have on this server, implements the PPP callback and not Microsoft's 
version but I don't think I should get this authentication failure.

Any ideas ?

Regards,

Colin

  <<< Note 481.11 by WOTVAX::16.183.112.224::warins.reo.dec.com::houston_c >>>
                              -< call back again >-

Hello Guys.

I am only getting time now to look at this dial back again. 

Someone mentioned dnas 2.2 as the fix for my WIN95 dial back problem. However 
the supplied work around (&c0 s0=1) will not work in my case as I am not even 
getting as far as getting properly authenticated when I use the call back 
option for the users account. That makes me think I am doing something else 
wrong.

In summary:

I have WIN95 users dialing in PPP and being authenticated by the servers realm
account d/b. That side works fine.

However as soon as I take one of these working accounts and modify it for 
"mandatory call back" I get user authentication failure as follows from a 
WIN95 client: 


Local>
Event: Login                                     Time:  87 20:45:38
   Port: 7            Access:  Dynamic
   Username:
Event: Session Connect Attempt                   Time:  87 20:45:38
   Port: 7     Sessid: 1       Protocol: PPP     Access: Local
   Username:
   Peer: RESV_DSERVICE
Local>
Event: Login                                     Time:  87 20:45:39
   Port: 7            Access:  Dynamic
   Username: testacb@belfast
Event: Dial Request Failure                      Time:  87 20:45:39
 Port: 7        Mode: Unknown    Service:
 Username: testacb@belfast
 Reason: Authorization failure (dialback mode)
Event: Session Disconnect                        Time:  87 20:45:39
   Port: 7    Sessid: 1        Protocol: PPP
   Reason: Normal  TX: 181 bytes    RX: 184 bytes
   Username: testacb                    
Event: Logout                                    Time:  87 20:45:39
   Port: 7    TX: 181 bytes    RX: 184 bytes
   Username: testacb@belfast


Port seven on the server is configured for "dial back" so I presume that is 
why the peer changes to "RESV_DSERVICE". When the same user is used on a port 
not configured for "dial back" the same error results.

However if I edit the user account on the DS90M and remove "mandatory call 
back" the account authenticates and works ok regardless of the port.

Local>
Event: Login                                     Time:  87 20:51:00
   Port: 7            Access:  Dynamic
   Username:
Event: Session Connect Attempt                   Time:  87 20:51:00
   Port: 7     Sessid: 1       Protocol: PPP     Access: Local
   Username:
   Peer: RESV_DSERVICE
Local>
Event: Login                                     Time:  87 20:51:01
   Port: 7            Access:  Dynamic
   Username: testacb@belfast
Local>
Event: IP Address Set                            Time:  87 20:51:04
 Port: 7         Address:   16.183.112.107
Local>

I know that dnas 2.0, which I have on this server, implements the PPP callback
and not Microsoft's version but I don't think I should get this authentication
failure.

Any ideas ?

Regards,

Colin

> Someone mentioned dnas 2.2 as the fix for my WIN95 dial back problem.

Correct.  You can't use callback with Win95 until then.

> However the supplied work around (&c0 s0=1) will not work in my case...

Huh?  What work around?

> However as soon as I take one of these working accounts and modify it for 
> "mandatory call back" I get user authentication failure as follows from a 
> WIN95 client: 

This is what I would expect.  Since the callback is "mandatory" and your
client can't negotiate it (with LCP callback) the port is logged out for
lack of "compliance" with the mandatory authorization requirements.
Mandatory authorization characteristics mean "do what I say, or leave"!

> However if I edit the user account on the DS90M and remove "mandatory call 
> back" the account authenticates and works ok regardless of the port.

Just so.

> I know that dnas 2.0, which I have on this server, implements the PPP 
> callback and not Microsoft's version but I don't think I should get this 
> authentication failure.

Yes you should!  :-)

Regards,

Dave

Thanks for the reply.

Any idea of the availability of the dnas 2.2 kit ? Will it be available on the net in any form FT 
or otherwise ?

Colin

RE: .14

> Any idea of the availability of the dnas 2.2 kit ? 

Late Q4.  For a more specific date, contact product management.

> Will it be available on the net in any form FT or otherwise ?

We are starting FT next week.  If you are interested in participating,
go to our engineering web page for the FT Questionaire.  For internal
sites, a simpler reply would probably be acceptable.


	http://www-ra.lkg.dec.com/

more specifically

	http://www-ra.lkg.dec.com/index.html#FieldTest

Respond to DELNI::J_SILVERIA.

The distribution site for the FT kits will also be on the web:


	http://www.service.digital.com:80/netrider/

more specifically

	http://www.service.digital.com:80/netrider/download/download.html

but is password protected, so you need to register for FT first.

Regards,

Dave

Hello.

I finally got the DNAS2.2 FT on and eventually got dial back configured and working. 

Just one quick thing.

IF a Decserver port is configured to allow dial back I don't seem to be able to get clients 
access without the dial back permission on their server Realm user accounts. 

Is it only possible to give access to users with the dial back permission on these ports ? 

Colin

RE: .16

> Hello.

> I finally got the DNAS2.2 FT on and eventually got dial back configured and 
> working. 

> Just one quick thing.

> IF a Decserver port is configured to allow dial back I don't seem to be able 
> to get clients access without the dial back permission on their server Realm 
> user accounts. 

Correct.  The DIALBACK permission is required when the user _requests_ a 
"voluntary" dialback (either via PPP or by the command line).  If the user 
is configured with FORCED CALLBACK enabled, then it should happen 
automatically (of the user doesn't get to stay connected).

> Is it only possible to give access to users with the dial back permission on 
> these ports ? 

No.  The port characteristic is necessary, but not sufficient.  You could add
the DIALBACK permission on the SERVER REALM default authorizations, which would
cause all users who authenticate locally to inherit that permission.

> Colin

Regards,

Dave

Hello Dave.

I think I should have worded my question differently.

What I meant was:

when I have a port configured for "dial back" it appears to me that users who previously had "dial 
up" access to that port will no longer authenticate. They will not authenticate correctly until I 
give them the "dial back" permission on their local server Realm user account. That seems to imply 
"dial back" and nothing else on that port.

To put it another way is it possible to have one port configured to allow a mixed bunch of clients 
both "dial back" and "dial up" access to that port? This would be nice because for some people 
"dial back" access is not always possible, for example from Hotel rooms.

If it is not possible then you have to configure your server with separate "dial back" and "dial 
up" ports.

Thanks

Colin

RE: .18

> Hello Dave.

> I think I should have worded my question differently.

> What I meant was:

> when I have a port configured for "dial back" it appears to me that users 
> who previously had "dial up" access to that port will no longer authenticate.
> They will not authenticate correctly until I give them the "dial back" 
> permission on their local server Realm user account. That seems to imply 
> "dial back" and nothing else on that port.

OK, I think this is may be a bug.  And I think it's one that we might have 
fixed in the T.2. field test update (available as of today).  Why don't you 
access the new FT kit and try it?  (Contact me offline if you don't know how
to get it.)

> To put it another way is it possible to have one port configured to allow a
> mixed bunch of clients both "dial back" and "dial up" access to that port?

Yes, that _should_ work just fine.

> This would be nice because for some people "dial back" access is not always 
> possible, for example from Hotel rooms.

Right.

> If it is not possible then you have to configure your server with separate 
> "dial back" and "dial up" ports.

Right.  Not what we intended.

> Thanks

> Colin

Regards,

Dave