Members using LDS Id's to authenticate in meeting houses

[dfdavis]

We've been having the exact same problem in our stake center: stake presidency + 3 overlapping wards + family history center... we've been running out of IP addresses every Sunday. Just upgraded to one of the new firewalls this week and increased our DHCP range. I'm also going to assign static IPs to all of the clerk computers and family history computers. So hopefully that helps the problem and at least all of those systems always have connectivity. Seems this is going to be a growing problem everywhere with an increasing percentage of people in the building having some type of wifi device.

on your comments....I am still back to one of my original observations and comment here. IMHO...just calling support and getting more assigned IP's are not the answer to any our problems. At some point, this practice just has to stop. The service to your buildings only have "X" amount of bandwidth. And will only support X amount of users.
With this "new to come system" of members logging in using their LDS username and password, will admittedly help....for a time. The new system with supposedly 3 levels of permissions granted by our leadsrship...I still have to wonder...how does someone's phone or device know that I am a youth and not allowed to connect to the building system? What if I, as a youth have Dad's old smartphone? I wish things were all blue skys and green lights....but at some point our global support people are going to have to deal with the much bigger issue. I have an answer but nobody likes mine.... Granted, it does not fix the problem but it sure limits the number of allowed users. again..IMHO, not everyone in our buildings needs to be connected the whole time they are there.....good luck to any of us who think they can control that.

[aebrown]

The new system with supposedly 3 levels of permissions granted by our leadsrship...I still have to wonder...how does someone's phone or device know that I am a youth and not allowed to connect to the building system?

The new system uses LDS Account authentication. It's not that the phone knows that you are a youth -- no device can get an Internet connection without actually entering LDS Account credentials, and associated with your LDS Account is the membership number, and associated with that is the age of the person. So the authentication system knows how old the person logging in is. That seems pretty straightforward.

What if I, as a youth have Dad's old smartphone?

That's really a question of whether the authentication credentials can be stored on the device. If not, then there's no problem at all with a youth having a device that previously connected -- they'll have to enter in their LDS Account credentials again each time they enter the building. If the credentials can be stored, then anyone who passes on a device to someone else has a responsibility to clear them, just as with a computer that might store credentials. We'll have to wait to see the details on whether credentials can be stored.

[Aczlan]

We use a walled garden system at work (OpenWRT on a Linksys WRT54GL with Wifidog installed).
We have also looked at other "Walled Garden" systems and they all seem to work about the same way.
1. The user connects to the wireless network and is assigned an IP address
2. The user tries to access the internet.
3. They are blocked and redirected to a login webpage.
4. The user enters their credentials and based on the login rules (in this case, their age and calling) that IP/MAC address is unblocked or left blocked.
In step 4 it is possible for the user to save their credentials as with most webpages.
If the user saves their credentials, anyone who uses that device can access the internet as the user who saved their credentials.
So, a youth could login with Dad's old smartphone, if the saved credentials were not cleared, but that is no different than Dad giving said youth his credentials.

In our system, the user is prevented from accessing anything other than the internet outside of the "walled garden" via firewall rules.
If anyone is interested, I would be happy to explain in more detail offline.

Aaron Z

[sammythesm]

The service to your buildings only have "X" amount of bandwidth. And will only support X amount of users.

You're right, but I think the "X" numbers your thinking in your head are artificially low. Because of the nature of IP, you can have a lot of connections with still relatively low bandwidth usage.

Think of it as a community swimming pool - the pool is actually quite small. But the pavement around the pool for people to lounge about is quite large. Let's say the pool deck can hold 300 people, but the pool will only hold 50 'recreational swimmers' OR about 10 people swimming serious laps.

Most church-goers are just sitting on the deck. After all, we come to church to attend the meetings - which should hold their attention. Sure, their device may auto-connect when they enter the building, but aren't actively using the connection for the majority of the time - and the nature of IP is such that a single connection has little to no cost to the overall performance of the network. They may get some push notification from their carrier, or fire off an email, or refresh their facebook feed (when the high council speaker drones on), but those are all lightweight operations. They get into the pool, then quickly get out of the pool. Rarely, at one time, are all 300 people attempting to get into the pool at once - or attempting to swim laps at once.

The challenge comes whenever you have people who want to swim laps with the recreational users (bandwidth intensive operations like streaming video upstream, stream video downstream). If 50+ users try to get into the pool while the guy is trying to swim laps, it's going to be a futile effort for our lap swimmer. In this case, someone needs to blow the whistle and get everyone out of the pool, or section off part of the pool. Similar things can be done in the network design. "Buoys" (VLANs, QoS, bandwidth throttling) can be set up in the network to artificially lower the space people can get in and get out with the idea that they can still enjoy the pool while the lap swimmer gets done what he needs to get done. At some point, he may need the whole pool so everyone will have to be forced out (disable the wireless altogether).

My experience has been, that in situations where people are sharing bandwidth, they tend to figure out how to be good neighbors to each other. Sure, a network administrator may need to take action for special circumstances, but I don't think - generally - we should artificially limit who can log on to the network just because we fear they may use it and push it to its limit. Networks are resilient, and people will figure out their limits and live within them.

[rbeede]

Actually a plus might be that reaching the limit consistently every Sunday could give reason for the stake president to ask the STS and FM Group about negotiating a faster connection with an ISP.

[dfdavis]

Actually a plus might be that reaching the limit consistently every Sunday could give reason for the stake president to ask the STS and FM Group about negotiating a faster connection with an ISP.

I can see from some of the comments.... there are people who have not had any of these problems yet.

[earthspiritraven]

Well, after reading this thread I'm consoled in the fact that I'm not the only one pulling my hair due to network issues. In the stake I'm in there are two buildings with the new wireless cisco machines with only the LDSaccess login each of which has two wards, and one building with a DSL wifi modem and an old pix cisco in which there are three wards, the stake and the FH center. After a couple of meetings with the stake presidency it has been decided that for now only bishopric can use the wifi with LDSaccess and the DSL modem wifi access. But of course that has made my life complex when having family history and indexing events. Under the current setup it has meant that I have had to take my own wifi router to each building to give generalized access in these events.
Does anyone have a good idea on the time frame for the LDS account login system? The Stake president has asked me of ways to generalize access for other leaders and members for using church resources for church related activities. I researched about the cisco and wanted to get GSC to create a second virtual access, but now with this information I'm relieved that it might happen anyway... but when?
Fortunately I do not have the problem of running out of IPs given that the access has been restricted by the SP, but surely that might happen when the access is generalized. A class C subnet *254 IPs) surely would give more or less adequate access for members in the two smallish buildings, but definitely not in the stake center. Is more than one class C subnet possible in the cisco for the +/- 300 persons at peak time?

[sammythesm]

Couple things:

For your "DSL wifi modem access" - is that wireless device INSIDE the church firewall? Otherwise it is out of policy and it's not being filtered. Might want to look at that and make sure it's set up right.

For the building with the Pix, the solution is simple - upgrade to a Cisco 881. More IP addresses can readily be added to an 881. More than 1 class C can be added as well, though the GSC might work you over a bit to verify that you really need the IPs.

[johnshaw]

sammy... it's not simple. My FM will not upgrade my Pix to an 881. I had a failure last night at a General Priesthood meeting because I couldn't get an IP address on a computer due to the IP's being so limited, this has been going on in at least 3 buildings I have and FM says no budget to do it.

[russellhltn]

sammy... it's not simple. My FM will not upgrade my Pix to an 881. I had a failure last night at a General Priesthood meeting because I couldn't get an IP address on a computer due to the IP's being so limited, this has been going on in at least 3 buildings I have and FM says no budget to do it.

That sounds like an issue with your particular FM group.

If FM is not being responsive, I'd inform the Stake President of the situation.