Jump to content
Vodia PBX forum
netpro78

Provisioning Username and Password

Recommended Posts

Is there a way to create a username/password per domain that will allow downloading of config files?  Right now only the extension web usernames/passwords seem to work, and while it is more secure, it would be much easier to have the option of a domain level username/password that would permit provisioning.

Share this post


Link to post
Share on other sites

I am referring to a username/password that can be used on all phones in the domain to download their config, that would be a great feature for a future version, and make me more likely to utilize the built in provisioning of the PBX instead of hand writing config files, and hosting them on a separate server.

Share this post


Link to post
Share on other sites

Generally speaking, at least by default the PBX should never leak out passwords. However, you can (should) use the REST API for this. By default downloading passwords is disabled; there is a setting in pnp.xml called rest_show_passwords that you can change to true to make this possible. Then you can use the /rest/domain/<domain>/user_settings/<account> API call for this.

Share this post


Link to post
Share on other sites

Really all you would need to do is to make the pbx do is accept the username/password of users in the domain admin field for phone provisioning requests.  right now I can work around it by creating an extension just to provision with, however that is a waste of a license.

Share this post


Link to post
Share on other sites

One small glitch I found with using an account just for provisioning is that the system fills the LDAP credentials in based on the creds used to log in, and not based on the extension that the MAC is bound to, so that would need to be corrected.

Share this post


Link to post
Share on other sites

LDAP is actually a headache because only very few devices support TLS or at least Digest authentication. In other words, the password crosses the wire when a user presses the address book button, not good. What should we do with devices that don't use LDAP with TLS or use at least Digest authentication.

Share this post


Link to post
Share on other sites

It is not as much of a LDAP issue is it is an issue with the way the system builds the config files.  I would propose that there be an account type at the domain level that has permissions to download config files for the domain.  Then when the system generates the config file, it fills it with the credentials of the account that the MAC is bound to, and not the credentials of who is logging in to get the file (like it currently does).  It would probably also make sense if there was a separate password for LDAP since web, sip, and VM all have individual passwords. 

Share this post


Link to post
Share on other sites

You cannot trust an endpoint. If you give one endpoint the credentials to pull all configurations for a domain, you can as well just give all endpoints the same username and password...

Share this post


Link to post
Share on other sites

Yes, and you cannot trust an end user to update their phone's provisioning password in the phone if they happen to update their web password.  Possibly each extension should have separate passwords for each function:

LDAP password

SIP Password

Provisioning password

Web portal Password

Voicemail PIN

Share this post


Link to post
Share on other sites

The LDAP password is on our list... SIP password should be in a good space because we practically have a separate SIP password for each provisioned device. The web password is practically "the" account password now, and the PIN the IVR password.

Share this post


Link to post
Share on other sites

The provisioning password would be the "key" to the SIP password and the LDAP password (and the PIN). Why not putting them together into a client/device password? At the end of the day, the device needs only one password, there is no further user interaction anyway.

Share this post


Link to post
Share on other sites

Because right now the provisioning password is the same as the web password, and it is a regular activity for the end user to change their web password.  It is not normal for them to change the provisioning password on the phone, and therefore they should be separate.

Share this post


Link to post
Share on other sites

The provisioning password is today the MAC address password. You can also provision a phone with the web "master" password, but that is not suggested and that is not in the latest templates. IMHO that is the right way to do this. In the next version we will generate a special LDAP password; then a VoIP phone should never have to use the web password or the SIP password. Having the LDAP password separate solves the problem that many VoIP phones don't support TLS for LDAP which makes this password specifically exposed. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×