PIN Set Enhancements

hraynor

Guru
Joined
Feb 11, 2009
Messages
137
Reaction score
1
We're using PIAF at two (soon to be more) non profit recovery facilities in the area. Each site has about 20 extensions and due to the nature of what they do, we use PIN set codes on all phones (except for one in a locked phone booth) to allow for outside calling.

Each staff member has their own PIN number, and this generally works "ok" and (with modifications to reporting to add "accountcode" back in) we can pull reports on whose code was used.

All great. However, overall the PIN set approach is very lacking in many ways. Primarily in that its just a big list of numbers, with no way to easily associate what code belongs to whom. As well, this is separate from the LDAP server (we use ClearOS) where we otherwise create users.

Also, when running reports, we only see the PIN code, but I would love to be able to see some username instead (especially important if PIN codes may change often, as they should).

What I'd love to see would be the ability to have PIAF (or FreePBX generally) to access an LDAP server to validate PIN codes. Perhaps even a two tiered system, instead of a single PIN code, user would type their account number, followed by a password. ie:

6327#2891#

where perhaps 6327 is a unique code identifying the user (perhaps that would never change) and 2891 would identify the "password" that might change from time to time. This could then be easily sent to the LDAP server for validation.

And this way, one when running reports, one wouldn't have to be concerned with the PIN code for a particular user changing, ie: in my example 6327 would always be assigned to the same person (and thus perhaps 6327 would appear as the accountcode in reports), but the password could change for security purposes.


In addition, having this ability would also give us the ability (if we desired) to be able to assign phone codes to each of the 75+ residents between the two facilities, so we could (on the LDAP side) not only know which residents (not just staff) are calling, but set restrictions of when they could call, how many calls per day, etc. (in theory, of course this would require more development, perhaps on the LDAP server side).

It would also allow us to (hopefully) use a single interface (in our case ClearOS - would require a ClearOS plugin of course) to be able to grant users phone access, assign accountcodes, change passwords, etc.


As a model for how I see this, we would like to be able to handle voice/telephone calls just like how we create users in ClearOS today - ie: I create a user, decide what access he/she gets (email, file server, FTP, shell access (ie: to use an LTSP terminal), etc) and boom, done! Clear does everything including configuring email account (if enabled), etc. Makes administration VERY easy, and also means that I (as a total volunteer totally handling everything on the infrastructure side for these two facilities (including running cable, etc)) could easily show someone how to do this (I already having the staff, some with no computer expertise, creating and managing users - took 15 minutes to show them and have had not issues - would never have them add/delete PIN sets in PIAF as too much potential to mess things up for others).

I don't see this as a tremendous thing to create, and if someone else is interested would be willing to work together to make it happen, though not sure I have the time to do this all myself.

BTW - if one looks at my other request (PIAF running under ClearOS, then one could see that this feature could be merged to really create a killer system).
 
BTW - let me also add that for my use case, the residents would NOT have an extension or voice mail (and we would have no desire to provide this).

Thus, any solution that would in any way rely on this wouldn't work for us.
 
Thanks for the information, will look into your suggestions.

Due to the nature of what we're doing, we need to ensure that the residents only have access to the phone system when allowed to. Thus, it does require some compromises by the staff, so I don't see putting the employee num and password everytime as a big deal.

But that said, I agree if it was a two prompt approach ("Enter ID", user does this and #, "Enter Password") that this would be very annoying. I agree with your suggestion to use * as a separator between user and password to be the best way, so this makes perfect sense (or if we want to fix the number of digits in the user to 4 say, that would be easy as well).


Reason I don't like the login is that the staff often walks away from the phones with the offices unlocked, at times for emergencies. Thus, we can't guarantee that the phone would be logged out.

Part of the reason for controlling resident access to phones is for various liability reasons, given the nature, so we need to make sure we monitor this carefully.

I'll look at your idea of syncing the databases. This might actually help things be a bit more straightforward as I wouldn't have to make any changes on the PIAF side.

That said, I could still see this as having some issues, perhaps reporting (though if I can use a wildcare in accountcode field to just search on the username side, that might help - though this also exposes passwords in the reports).

Few other things as well, but that might be a great first step.

Hardest thing I think is figuring out on the ClearOS side where in the LDAP schema to add the new fields (phone user id and password) and then whether to add a new module (easy) to Clear, or modify the existing User page (nicer result by far, one single page, but don't want to modify something already there - perhaps they have a way to extend this? Need to research).

I might actually take your approach (DB sync) as the first step as it lets me focus on the ClearOS side first.
 
1. I probably answered my own question, but do the SIP phones have the ability to disable the redial button?

2. For reporting, can't you make each account code a uniform 4 digits and write a stored procedure that used select "left(field,4)", etc?

3. The worst type of attack to defend against is privilege escalation from an internal user, and if they have time on their hands, it's a losing battle.

4. I would look at how a correctional facility handles their calls, and try to mimic their proprietary security measures.
Specifically the greeting:
"You are receiving a (collect) call from (institution). This call may be a scam and will be recorded. If you accept these terms, press 1. To be added to our blocked caller list, press 2."

Best of luck,

Charles
 
I believe you can indeed disable (or remap) the redial button on many SIP phones, however I don't think this would enable you to get around the PIN set. Redial would most likely just "replay" the digits dialed prior to hitting Send or # on the phone (ie: at this point the phone sends an INVITE to Asterisk).

With the PIN set setup in FreePBX, you dial the number (and then the phone sends an INVITE) and then Asterisk prompts you for the PIN. Thus the phone wouldn't remember that PIN as part of redial (just the initial number dialed). At least that's my belief, I'd have to test it.

It is true that if someone would to create a dial string such as 8005551212,,,,,,1234 on the phone before pressing SEND (ie: dial 80005551212 wait a few seconds and dial 1234# as the PIN) that this indeed most likely would get put so the redial could be pressed, but most people don't do this.

In my case, I'd probably want something similar - dial the number, then Asterisk prompts for the PIN (or user/pass combo).

Good point on the account code. Most likely I'd want custom reporting anyway, as I'd probably want to lookup the name of the user for the reports.

Not sure what you are referring to in #3. Here the only access the residents would have would be this user/password to make outbound calls. That's it, no extension, no acd login, etc.

#4 is interesting, though probably not something we'd do considering our goals of trying to reintegrate them into society. ie: in many cases they use the phones to do job searches, etc - so a message such as that might be totally counter to that goal and scare off potential employers (though I see its merits on other matters).

Still thinking of how to do all of this. Another thought would be how would a user change his/her phone password? I could whip up a web page as most would have access to the computer room (also monitored and filtered), but perhaps a simple IVR to allow this to be changed would be waranted (though if one wishes to force password expiration, not sure how to notify that by phone (since they won't have their own extension) unless its on the outbound call to force this - will have to think about this).

Guess its time to writeup some requirements. If I develop this myself, I would want it to be something usable by others and not just specific to these installs (ie: be able to be integrated with ClearOS/LDAP but not require perhaps).
 
Not sure what you are referring to in #3. Here the only access the residents would have would be this user/password to make outbound calls. That's it, no extension, no acd login, etc.
In a past position, I was told to support a disgruntled employee, by HR. We disabled the USB/CD-R/locked down Active Directory. Despite all of this, because he knew how the system worked, he still found a way to do damage.

The only experience I had from jail was a HS bully making collect calls over and over, trying to harass. I'm not sure it you're state allows one-party consent for recording. (or if the residents can give consent.)

I would call around other facilities, and consider building an OSS version of whatever they're doing. That way you aren't sticking your neck out too far.

That said this sounds like an awesome volunteer project, and I wish you the best of luck,


Charles
 

Members online

Forum statistics

Threads
26,686
Messages
174,407
Members
20,257
Latest member
Dempan
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Back
Top