Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
The term “bring your own device” also known by the acronyms “BYOD” and “BYOT” refers to the concept of organizations and companies allowing their employees to bring their private, mobile devices to the office and use them. This can present a number of advantages for both employees and organizations alike, for example:
In addition to the advantages listed above, the development also goes hand in hand with a whole range of legal, organizational, and technical challenges.
In this article, I would like to concentrate in particular on the technical challenges and illustrate how the bring your own device concept can be realized efficiently and securely. A comprehensive overview of the legal challenges can be found in Bitkom’s bring your own device guidelines (in German).
Examples of additional organizational and technical challenges associated with the use of private devices include:
These challenges can be a reason for an organization to choose providing its employees with mobile end devices and thus avoiding the use of private devices. This scenario is also known as “get your own device” (GYOD). This article does not deal directly with this concept, although many of the technical challenges also apply accordingly.
Access to the organization’s IT infrastructure and the IT applications is a fundamental requirement for the use of mobile devices. As such, bring your own device is only practically possible when there is a high-performance WiFi infrastructure in place to allow reliable working with mobile devices. The increasing availability of affordable data plans for cell phones may be reducing dependency, but we are still far from the day where all types and models of mobile devices are equipped to access mobile networks, e.g., tablets and laptops. WiFi is the most popular interface supported by all types of devices. Consequently, setting up a WiFi network is the first important step towards implementation of bring your own device.
Even in small organizations it can be assumed that there will be more mobile devices than employees in next to no time. In order to maintain a clear overview and ensure that only your own employees use the wireless Internet and not unauthorized third parties, access to the network must be restricted.
The traditional WiFi password (pre-shared key) we are all familiar with from our routers at home is not suitable for this purpose. This impersonal password practically begs to be shared and thus control is easily lost. The whole idea behind bring your own device is that employees are put in a position to work productively with private devices. As such, the security requirements are far higher than when providing Internet access via a guest WiFi network.
RADIUS (Remote Authentication Dial In Use Service) has managed to establish itself in the industry for the securing of WiFi infrastructures. RADIUS allows secure authentication of users by drawing on the accounts in the LDAP or Active Directory directory service (Link zum kurz erklärt-Artikel), for example. This means that employees log in to the organization’s wireless network with their personal user account and password. It is much less likely that these credentials will be passed on to third parties. Another special aspect is that each employee knows his or her own login credentials and is not likely to forget them. Stricter security precautions such as authentication with certificates and restricting access to known devices are also possible with RADIUS. In addition, RADIUS offers extensive possibilities for logging and regulating access which are relevant for organizations.
The enterprise operating system Univention Corporate Server offers a RADIUS app in the App Center which connects the RADIUS service to the supplied LDAP directory service. The app is a free add-on and can also be used in the free Univention Core Edition to secure an organization’s WiFi network.
Once the mobile devices join the wireless network, it becomes necessary to ensure these devices can also access the Internet. In larger organizations it is common to restrict Internet access by having proxy servers filter contents and, if applicable, only permitting authorized users access. This can be practical to prevent attacks from viruses and trojans or to block popular specific sites known to have a negative effect on productivity, for example.
This proxy can be used largely transparently on a workstation system in an organization. The proxy is stored in the operating system via group policies or autoconfiguration mechanisms in the web browser. The domain login is reused for authentication on the proxy. This makes it possible to operate a proxy without excessive efforts on the part of the IT helpdesk and IT administration for its operation.
These requirements are not met in mobile devices. They are privately owned, i.e., normally they are not integrated in the organization’s domain. Transparent reuse of the domain login is therefore not possible. In addition, we are still a long way from all mobile operating systems and apps supporting automatic configuration. As such, the use of a proxy requiring authentication is not practical.
The use of a transparent proxy is an alternative to a proxy requiring manual configuration. This requires no authentication and acts as a gateway to the Internet. This restricts the accountability for the Internet use to one specific employee, but also still allows securing of the Internet access without putting strain on the IT helpdesk and IT administration. In addition, compatibility with apps is considerably higher than with a regular proxy.
There is no doubt that a high degree of security is necessary. Organizations need to protect their corporate secrets from unauthorized access and ensure that the production process goes without a hitch. Both of these are at risk at all times and need to be protected by the IT administration. Bring your own device therefore increases the risk potential considerably.
Unlike devices belonging to the organization, the IT administration has no technical access to the private devices initially. As such, software distribution, patch management, and virus scans are not possible without additional measures. This sees organizations faced with a series of technical and organizational challenges.
One possibility: An organization can impose restrictions on the use of private devices, which make it possible, for example, to use mobile device management and attain a high degree of security. At the same time, the efforts required for the introduction of bring your own device increase and the employees’ freedom when it comes to choosing the devices is presumably severely restricted.
Instead of addressing the administration of the devices, it would therefore be a consequent step to restrict bring your own device to WiFi and Internet access, and to isolate the mobile devices strictly from the data worth protecting and the IT infrastructure in order to prevent access. From my perspective, this measure should be recommended. As usual for the configuration of a firewall, all accesses should be blocked to begin with. It is then possible to begin at this minimal level, gradually and taking security into consideration, to approve functions and IT services for use via BYOD and therefore really profit from BYOD.
Google is a prominent representative for a sophisticated, organization-wide security concept. In the “zero trust” model, access levels and requirements are defined for all services. Devices and employees must satisfy these requirements to be granted access to the IT services. Google’s concept goes far beyond the approaches dealt with in this article, but demonstrates that security is possible.
Once the mobile devices have been secured or access to the IT services has been completely blocked, the question poses itself of which services can be practically used via bring your own device. In this respect, the use of e-mail and groupware services in particular needs to be taken into consideration. By their very nature, these services are used to communicate with possibly unknown third parties and are generally secured and additionally laid out for high availability. Availability in particular is very important for bring your own device as the devices are used both in the organization and outside, independent of time and location.
Microsoft developed the proprietary ActiveSync protocol for accessing groupware services on mobile devices. This makes it possible to “push” new messages and changes to mobile devices if and as necessary. Microsoft Exchange and the most common competing products implement ActiveSync. Mobile devices with Android and iOS operating systems also support the protocol and can use it to view e-mails, calendar appointments and address book information directly.
Univention Corporate Server makes the integration of groupware services and the use of ActiveSync very simple as many of the common solutions like OX, Zarafa, Kolab, EGroupware, and Tine 2.0 can be installed directly from the App Center. In addition, the App Center also includes a whole range of further IT products from other vendors which can be practical for use via mobile devices.
If the plan is to make IT services with sensitive data available for bring your own device, imposing additional security requirements is a practical idea. One simple and useful step is the introduction of two-factor authentication (2FA) for these services. The App Center also has an app available for this in the solution privacyIDEA.
Bring your own device is a topic which is important for many organizations to address. A prerequisite for this is the implementation of a clear IT security concept prior to the introduction of BYOD. Building on this basis, the necessary technologies are now available to allow its realization with acceptable costs and provide both employees and the organization itself with added value.
Jan Christoph is with Univention since July 2008. He started his career as a software developer at Univention and joined the Professional Services team in 2009. Since then he has been involved in project management for large and small UCS projects as well as training and knowledge transfer. His personal interests are project management according to Scrum, version control systems, the vim text editor and the integration of Open Source Software components into useful systems. Jan Christoph's current position is Product Manager Education for Univention's UCS@school product.
that was great and excellent
can you help me how to implement authentication system in university and how i configure the radus server and further it which other server i must apply for user authentication in ucs server
We appreciate your interest, please refer to the Univention forum where our team can help you best with your problems. Thank you!