Page 3 of 4

Posted: Sun Oct 12, 2008 2:22 pm
by Mikerowaved
Ivan wrote:1) yes, we all would like remote access, in order to increase our flexibility of time usage, and reduce fuel costs, and 2) the security of remote access is very much a real concern that the church does not have a satisfactory solution for yet.

That probably sums it up.

Ivan wrote:Today, I found that this website is now blocked by the firewall. We had a good chuckle that this thread probably had something to do with that. :)

Not sure, but you might be experiencing the same firewall problem we brought up in THIS thread.

Cheers

Posted: Thu Oct 16, 2008 12:13 pm
by techgy
marianomarini_vi wrote:Maybe it can be done through a remote control software (VNC) and an Internet connection. This require branch's Pc always ON. Also this allow only one user at the time.


This may or may not work. VNC requires the client's IP address. The ASA firewall may block access to this address as well as the machine itself.

MLS in the Cloud

Posted: Mon Jul 13, 2009 8:22 am
by chadke-p40
I don't want to hijack this thread, but is there any movement afoot to put MLS into the cloud?

So much of this question about remoting into clerk's office PC would be solved if the Church moved MLS into the cloud and virtualized each unit's instance of MLS. Don't give us access to the central Church system, but simply run each unit's instance of MLS virtually.

Then the requirement on the user end is really simple: internet access and a machine capable of running a browser.

Even if the Church didn't want to do this on a Church-wide scale, couldn't it be done at the stake level with a relatively inexpensive "server" in the stake offices that virtualizes its units MLS instances and serves them up to the unit?

The workload of MLS is really rather light, it seems to me, and would be natural and likely fairly easy to move into the cloud.

Perhaps I'm just dreaming, but it seems like the remote desktop into the clerk's office approach is just a band-aid until we move the whole of this system into the cloud.

Posted: Mon Jul 13, 2009 9:22 am
by mkmurray
chadke wrote:...is there any movement afoot to put MLS into the cloud?

I think you might even be overthinking this by designing some system of virtualizing MLS instances on cloud servers.

There has been talk about the idea of moving a few MLS features at a time to the Web, specifically to LDS.org. The idea kicked around was that you log in using your username and password at LDS.org and get delivered all content and features related to your location and calling. This may include features that mimic many typical MLS use cases.

The first feature being talked about to move to the Web in this way is the Home Teaching and Visiting Teaching modules within MLS:

https://tech.lds.org/wiki/index.php/Home_Teaching_/_Visiting_Teaching_Application

Posted: Thu Jul 16, 2009 5:58 am
by chadke-p40
Thank you for the compliment: I'm not sure anyway has ever suggested before that I was overthinking something!

It simply seems to me that the technology has advanced to a place where the Church could gain great efficiencies by moving from an on-premise model for MLS to an in-the-cloud model.

What you're saying, though, about bringing features to the Web is really encouraging. Even if we did nothing more than bring the home and visiting teaching reporting to the Web, it would bring us to a new level of data accuracy.

Thanks for the insight!

Posted: Sun Aug 23, 2009 4:19 am
by jltware
Ok, assuming that I was using the remote connection for "diagnostic purposes" only and without starting the debate of whether or not this should be done again as I am quite happy to let my stake president interpret the policies and make decisions, how is it technically possible to open up the ports and program the firewall to accept connections. If the policies state that it can be done under certain circumstances, then I would expect the hardware and software on church computers to be configurable to allow such connections, even if it was only to be used when trying to fix a computer problem at the request of a branch six hours drive from the stake offices. So far as I can determine, the hardware firewall and router are all locked in boxes that even the stake president's master key doesn't open (apparently physical facilities are the only ones able to access this) and we dont have access to the passwords to log onto them. And the version of symantec firewall that came preinstalled on all our computers has all the configuration programs deleted and the options for even basic port forwarding blocked out. Short of deleting the firewall and starting over with a different security program, how can you configure the firewall. Has anyone successfully bypassed this problem. Does anyone know why the computers are set up this way in apparent disregard for the above quoted policy. Surely it is the stake president's decision what programs are installed on unit computers, and this is not the only situation where a program would need ports opened to be able to operate.

BTW, on the above post that quoted it being against church policy to connect any mls computer to the internet, that policy is very outdated now, and any mls computer can be connected to the internet as long as it is done under the stake president's direction and securely. This change was made under the direction of the presiding bishopric some time ago.

Posted: Sun Aug 23, 2009 5:41 am
by aebrown
jltware wrote:Ok, assuming that I was using the remote connection for "diagnostic purposes" only and without starting the debate of whether or not this should be done again as I am quite happy to let my stake president interpret the policies and make decisions, how is it technically possible to open up the ports and program the firewall to accept connections. If the policies state that it can be done under certain circumstances, then I would expect the hardware and software on church computers to be configurable to allow such connections, even if it was only to be used when trying to fix a computer problem at the request of a branch six hours drive from the stake offices. So far as I can determine, the hardware firewall and router are all locked in boxes that even the stake president's master key doesn't open (apparently physical facilities are the only ones able to access this) and we dont have access to the passwords to log onto them. And the version of symantec firewall that came preinstalled on all our computers has all the configuration programs deleted and the options for even basic port forwarding blocked out. Short of deleting the firewall and starting over with a different security program, how can you configure the firewall. Has anyone successfully bypassed this problem. Does anyone know why the computers are set up this way in apparent disregard for the above quoted policy. Surely it is the stake president's decision what programs are installed on unit computers, and this is not the only situation where a program would need ports opened to be able to operate.


The Church-managed firewall as described in Meetinghouse Internet is not surprisingly managed by the Church, specifically the Global Service Center. Local stakes do not configure the firewall. If you need assistance on specific requests, work with the GSC.

There is no disregard for Church policy in how firewalls or maintained. You just need to work through proper channels to request changes. The GSC is then aware of the more detailed policies that control firewall configuration.

jltware wrote:BTW, on the above post that quoted it being against church policy to connect any mls computer to the internet, that policy is very outdated now, and any mls computer can be connected to the internet as long as it is done under the stake president's direction and securely. This change was made under the direction of the presiding bishopric some time ago.


As with all policies and handbooks of the Church, updates occur by official letter. It is impractical to update every policy document and handbook every time there is a change, so the official letters extend the policy documents. I imagine that at some time in the future, the Policy and Guidelines for Computers Used by Clerks for Church Record Keeping will be updated, but until then, the policy includes that document and all subsequent relevant official letters.

Posted: Sun Aug 23, 2009 11:37 am
by MorettiDP
Hey guys... here the updated document!!! (from http://apps.lds.org/letters)

Posted: Sun Aug 23, 2009 3:49 pm
by jdlessley
jltware wrote:So far as I can determine, the hardware firewall and router are all locked in boxes that even the stake president's master key doesn't open (apparently physical facilities are the only ones able to access this)...
This appears to be a local policy since that is not the way it is throughout the Church. In order for the stake technology specialist to perform his duties as outlined in the Church Handbook of Instructions, Book 1, 2006, page 141, having access to the firewall and router is sometimes necessary.
jltware wrote:[T]he hardware firewall and router are all locked in boxes ... and we dont have access to the passwords to log onto them.
The Church provided security device (firewall and router) is managed by Church headquarters to ensure uniform and standardized configurations as well as to ensure supportablility and maintainablility of a system that can easily overwhelm the technical capabilities of members called to manage these systems. Just read the number of threads and posts from brethren called as stake technology specialists trying to understand setting up a local network. As Alan_Brown has pointed out the stake technology specialist can still configure the network security device by contacting the global service center and working with a technician.

jltware wrote:And the version of symantec firewall that came preinstalled on all our computers has all the configuration programs deleted and the options for even basic port forwarding blocked out.
Symantec firewall has nothing to do with accessability to the Windows control panel console applets or any similar restrictions to user interfaces of the operating system. Church headquarters used the features of Windows XP's configuration management to make those operating system modifications. They are still available to anyone who has the knowledge to access them or make any other operating system configuration changes. In these forums we do not advocate circumventing the operating system changes that have been put in place to protect the confidential material available on these systems.

jltware wrote:Short of deleting the firewall and starting over with a different security program, how can you configure the firewall[?] Has anyone successfully bypassed this problem.
We do not advocate bypassing security put in place by Church headquarters. Posting any such procedures, work-arounds, or hacks is a violation of the Code of Conduct of these forums. We should address issues to the Church IT people for resolution when necessary.

jltware wrote:Does anyone know why the computers are set up this way in apparent disregard for the above quoted policy[?]
To what policy are you referring? We have discussed the use of the remote access capabilities in other threads. The reference to remote access is quite dated and is well back in time before the [url=http://www.lds.org/Static%20Files/PDF/STS/Letters/English/06809_000_notice[1].pdf]11 February 2008 authorization to connect ward clerk computers to the Internet[/url]. As technology use within the Church changes so do the policies. For some, those policy changes do not appear in a timely manner. Until the issues discussed in this thread and others are resolved we must adhere to the policies in effect.

jltware wrote:BTW, on the above post that quoted it being against church policy to connect any mls computer to the internet, that policy is very outdated now, and any mls computer can be connected to the internet as long as it is done under the stake president's direction and securely. This change was made under the direction of the presiding bishopric some time ago.
Please note that this thread is quite old in itself. It wasn't until user chadke resurrected it that it came to life again. The quote was the policy in effect at the time.

Posted: Mon Aug 24, 2009 6:46 am
by jltware
The policy I am referring to is the one that says that stake presidents must (and therefore can) approve any third party software installed on a church computer within the stake. I read this in the guidelines downloaded from the mls.lds.org website, though I confess I haven't checked them recently to see if they have changed.

The symantec firewall is definitely blocking our computer from receiving connections on the relevant ports. We have tried hooking the computer up to a router temporarilly for diagnostic purposes, and found that it could still not receive the connection even on a local area network. It could however establish a connection to other computers and control them remotely.

I am familiar with some of the group policy changes that they have made to limit functionality, and have overridden several of them to allow the computers to use the microsoft update site. I do not believe in having computers connected to an internet connection unless the operating system, browsers and anti virus are up to date. Anything less than this is asking for viruses and hackers to have a good look through all your private information, which could be especially dangerous on clerk's office computers. I do not believe it is a group policy or operating system problem blocking access, I believe it is the firewall, though I would be happy to see any evidence to the contrary. It is difficult to establish with certainty however as all control of the firewall has been blocked, and the configuration applets have been deleted off the hard drives.

I do not believe remote access is the only situation where this problem would exist, as virtually any third party program that depends on internet access to function would require the opening of a port or two to allow it to operate. Hence my problem, and my frustration at finding that something that should be relatively simple to experiment with requires such extensive work arounds to get back to the baseline before programs can be configured.