netpro78 Posted September 21, 2017 Report Share Posted September 21, 2017 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. Quote Link to comment Share on other sites More sharing options...
netpro78 Posted September 22, 2017 Author Report Share Posted September 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 22, 2017 Report Share Posted September 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
netpro78 Posted September 22, 2017 Author Report Share Posted September 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
netpro78 Posted September 26, 2017 Author Report Share Posted September 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 26, 2017 Report Share Posted September 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
netpro78 Posted September 26, 2017 Author Report Share Posted September 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 27, 2017 Report Share Posted September 27, 2017 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... Quote Link to comment Share on other sites More sharing options...
netpro78 Posted October 1, 2017 Author Report Share Posted October 1, 2017 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 1, 2017 Report Share Posted October 1, 2017 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. Quote Link to comment Share on other sites More sharing options...
netpro78 Posted October 2, 2017 Author Report Share Posted October 2, 2017 How about separating the provisioning password? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 2, 2017 Report Share Posted October 2, 2017 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. Quote Link to comment Share on other sites More sharing options...
netpro78 Posted October 2, 2017 Author Report Share Posted October 2, 2017 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 3, 2017 Report Share Posted October 3, 2017 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.