Как интегрировать Active Directory с FreeBSD 10.0, используя security / sssd?

9

Каковы необходимые шаги для аутентификации пользователей из Active Directory, работающей на Windows Server 2012 R2 во FreeBSD 10.0, sssdс использованием серверной части AD с работающим Kerberos TGT?

Винициус Ферран
источник

Ответы:

14

Есть несколько хитрых соображений, чтобы все работало «из коробки». В sssdданный момент FreeBSD поддерживает только версию 1.9.6. Так что нет никакой поддержки для основных имен предприятий.

Если у вас есть домен с несоответствующими именами UPN, он не сможет войти в систему, так как аутентификация Kerberos не будет выполнена во время процесса, даже если FreeBSD поддерживает основные корпоративные имена с Kerberos, sssdэтот случай не может быть обработан.

Таким образом, в реальной версии sssdвы ограничены тем, что основное имя пользователя находится в одном доменном имени, например:

Domain Name = example.com
NetBIOS Name = EXAMPLE
User Principal Name:
username@example.com sAMAccountName: username

Зная это, мы можем описать шаги для успешной аутентификации пользователей из AD во FreeBSD.

1. Настройте Kerberos

Создайте файл /etc/krb5.confсо следующим содержанием:

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = yes

2. Установите Samba 4.1 и настройте его на присоединение к домену.

Установите Samba 4.1:

$ pkg install samba41

Создайте файл /usr/local/etc/smb4.confсо следующим содержанием:

[global]
    security = ads
    realm = EXAMPLE.COM
    workgroup = EXAMPLE

    kerberos method = secrets and keytab

    client signing = yes
    client use spnego = yes
    log file = /var/log/samba/%m.log

Спросите у администратора билет Kerberos:

$ kinit Administrator

Затем присоединитесь к домену и создайте таблицу ключей.

$ net ads join createupn=host/server-hostname.example.com@EXAMPLE.COM -k
$ net ads keytab create -k

3. Установите пакет sssd и Cyrus SASL с поддержкой Kerberos.

Установите необходимые пакеты:

$ pkg install sssd cyrus-sasl-gssapi

Отредактируйте файл, /usr/local/etc/sssd/sssd.confчтобы он соответствовал этим настройкам:

[sssd]
    config_file_version = 2
    services = nss, pam
    domains = example.com

[nss]

[pam]

[domain/example.com]
    # Uncomment if you need offline logins
    #cache_credentials = true

    id_provider = ad
    auth_provider = ad
    access_provider = ad
    chpass_provider = ad

    # Comment out if the users have the shell and home dir set on the AD side
    default_shell = /bin/tcsh
    fallback_homedir = /home/%u

    # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
    #ldap_sasl_mech = GSSAPI
    #ldap_sasl_authid = SERVER-HOSTNAME$@EXAMPLE.COM

4. Добавьте поддержку sssd в nsswitch.conf

Отредактируйте файл, /etc/nsswitch.confчтобы он соответствовал этим настройкам:

group: files sss
passwd: files sss

5. Настройте PAM, чтобы разрешить аутентификацию sssd и обработать создание домашнего каталога

Установите дополнительные пакеты для создания домашнего каталога:

$ pkg install pam_mkhomedir

Измените необходимые PAMобласти, чтобы соответствовать этим настройкам:

auth            sufficient      /usr/local/lib/pam_sss.so
account         required        /usr/local/lib/pam_sss.so        ignore_unknown_user
session         required        /usr/local/lib/pam_mkhomedir.so  mode=0700
session         optional        /usr/local/lib/pam_sss.so
password        sufficient      /usr/local/lib/pam_sss.so        use_authtok

6. Переключитесь на клиент OpenLDAP с поддержкой SASL

$ pkg remove -f openldap-client
$ pkg install openldap-sasl-client

7. Наконец подтвердите, что все работает

$ getent passwd <username>
Винициус Ферран
источник
Есть ли у вас решение для FreeBSD 10.3, где при установке openldap-sasl-client pkg удаляет sssd, ldb и samba44? Я чувствую, что я так близок, когда использую ваш ответ, но я застрял в этой части.
bgStack15
2

Какой Kerberos вы используете здесь? Встроенный или security / krb5 от MIT?

При установке sssd требуется установить security / krb5, который на данный момент все еще считается экспериментальным во FreeBSD. Таким образом, этот вопрос.

Мне не повезло в получении пользователей / групп AD при выполнении команд getent. это может быть связано с тем, что имя NETBIOS отличается от имени домена -ie в моем случае, имя домена - dawnsign.com, а имя NETBIOS - DSP.

Я настроил только модуль входа в систему pam.d. Какие другие модули pam необходимо отредактировать для успешной аутентификации?

Любая дополнительная информация будет принята с благодарностью!

Даг Сэмпсон
источник
Я использую Heimdal Kerberos с базы. Не устанавливается порт MIT Kerberos.
Vinícius Ferrão
1

Перекомпиляция samba4 из портов позволяет использовать аутентификацию winbind как linux даже без sssd. Просто перекомпилируйте samba4 из портов после включения sasl ldap

    pkg remove samba41 
    pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb 
    pkg remove -f openldap-client 
    pkg install openldap-sasl-client 
    cd /usr/ports/security/sssd && make install

Это перекомпилирует samba со всей необходимой поддержкой (gssapi, ldap, kerberos), а затем отредактируйте nsswitch.conf следующим образом

passwd: files winbind
group: files winbind
elbarna
источник
Зачем использовать winbind и samba, если мы можем использовать нативный Kerberos?
Виниций Феррао
Для активных пользователей каталога Kerberos предназначен для пароля, а sso
elbarna
0

Привет,

Это небольшое обновление по использованию sssd v1.11.7

Если вы используете "id_provider = ad" и видите следующую ошибку в лог-файле sssd:

/var/log/sssd/sssd_example.com.log
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-12)[Not Supported]
(Sun Oct  5 18:41:37 2014) [sssd[be[alidaho.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error]

Вы можете использовать следующую процедуру для решения этой проблемы и обеспечения правильной работы интеграции AD. Теперь соберите sssd v1.11.7 с поддержкой Samba, необходима сборка из src sssd, поэтому она связана с libsasl2

​pkg remove samba41
pkg install cyrus-sasl-gssapi samba36-libsmbclient pam_mkhomedir ldb
pkg remove -f openldap-client
pkg install openldap-sasl-client
cd /usr/ports/security/sssd && make install
syepes
источник
Какова цель удаления samba41? Это работает только с samba36? У меня именно эта проблема, но я не хочу возвращаться к 3,6, если мне не нужно.
MikeyB
Вы удаляете двоичный файл samba41, затем перекомпилируете samba41 из портов (запрашивается sssd). В моем случае (новая версия 10.1) бинарный файл samba41 не работает, samba41, скомпилированный портами, работает отлично
elbarna
0

Вот мое руководство по интеграции AD через SSSD с этими версиями FreeBSD на момент написания этой статьи (6/2017)

  • FreeBSD 10.3 и 11.0 (10.3-RELEASE-p18 и 11.0-RELEASE-p9)
  • Установка (и забавные вопросы упаковки и зависимости)

    • Требуемые пакеты не совместимы с Heimdal Kerberos, поэтому все должно быть установлено и скомпилировано с включенными флагами MIT Kerberos. Вероятно, это скорее проблема зависимости пакетов, чем проблема фактической совместимости.
    • Heimdal устанавливается вместе с базовой системой, поэтому после установки MIT Kerberos вы получаете два набора команд Kerberos: один набор /usr/bin, а другой - /usr/local/bin. Поскольку кажется, что ни один из базовых системных файлов не находится в пакете, вы не можете просто удалить содержимое Heimdal KRB. Что-то, о чем нужно знать.
    • Прямые зависимости различных пакетов (интересные deps жирным шрифтом, конфликтующие deps жирным курсивом):

      • net-mgmt/adcli:net/openldap24-sasl-client
      • security/cyrus-sasl2-gssapi: security/cyrus-sasl2
      • net/openldap24-sasl-client: security/cyrus-sasl2
      • security/sssd: security/nss
      • security/sssd:security/krb5
      • security/sssd: security/cyrus-sasl2
      • security/sssd:net/openldap24-client
      • security/sssd: lang/python27
      • security/sssd: lang/python2
      • security/sssd: dns/c-ares
      • security/sssd: devel/tevent
      • security/sssd: devel/talloc
      • security/sssd: devel/popt
      • security/sssd: devel/pcre
      • security/sssd: devel/libunistring
      • security/sssd: devel/libinotify
      • security/sssd: devel/gettext-runtime
      • security/sssd: devel/ding-libs
      • security/sssd: devel/dbus
      • security/sssd: databases/tdb
      • security/sssd: databases/ldb
    • Обратные зависимости различных пакетов:

      • net/openldap24-sasl-client: sysutils/msktutil
      • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
      • net/openldap24-sasl-client: net-mgmt/adcli
        • Как мы видим sssd, MIT требует Kerberos, хотя в качестве базового пакета у нас есть Heimdal
        • adcliхочет openldap-sasl-client, но другие пакеты (включая подчиненные зависимости sssd) openldap-clientизвлекаются, что является мьютексом с клиентом sasl (по какой-то глупой причине). Это затрудняет установку даже при минимальном наборе бинарных пакетов.
        • Эти зависимости присутствуют как для бинарных пакетов репо, так и для пакетов, встроенных в дерево портов. Это требует раздражающего метода установки, чтобы получить все, что нам нужно (см. Ниже).
    • На момент написания статьи бинарный пакет pkg для SSSD для FreeBSD не включал поддержку AD в SSSD.

      • Версия портов SSSD должна была быть собрана с включенными соответствующими параметрами (make config):
        • SMB
      • SSSD также хочет подключить openldap-client, когда ему действительно нужен openldap-sasl-client для правильной работы.
    • Двоичная версия pkg adcliсуществует, но на момент написания статьи не работает.
      • Опять же, версия портов была скомпилирована с соответствующими параметрами:
        • GSSAPI_MIT
    • cyrus-sasl-gssapi требуется, но двоичная версия pkg не работает и имеет странные проблемы с зависимостями, которые приводят к удалению SSSD.
      • Соберите его из портов с включенной опцией MIT-KRB5:
        • GSSAPI_MIT
    • openldap-sasl-client требуется для функциональности, но SSSD хочет использовать версию openldap, отличную от SASL.
      • Чтобы сделать эту работу
        • настроить openldap-sasl-clientс GSSAPIпараметром selected ( make config) в портах.
        • Сделайте make в портах, чтобы собрать его
        • Перед установкой сделайте pkg remove –f openldap-client
          • Это удалит openldap-clientбез каких-либо автоматических удалений любых других пакетов (например, SSSD) и позволит установить версию SASL
        • Сделать make install для openldap-sasl-client
          • Это установит его в систему
    • Это обеспечит то, что необходимо для функционального SSSD с возможностями AD.
    • Обратите внимание, что если вы скомпилируете SSSD из портов, он получит МНОЖЕСТВО зависимостей, что приведет к их построению и потребует выбора параметров конфигурации.
      • Рекомендуется сначала установить двоичный пакет с помощью pkg install sssd, а затем удалить его pkg remove –f sssd
        • Это приведет к тому, что бинарные пакеты для большинства вещей, в которые нужно вставить SSSD, будет устранено, и избавит от необходимости строить все это в портах, что занимает довольно много времени.
      • После удаления переустановите SSSD из портов с включенными вышеупомянутыми опциями, и вам потребуется только пересобрать четыре пакета, упомянутых выше, чтобы получить рабочую настройку.
    • (Необязательно) Когда все работает и проверено, вы можете использовать pkg createдля создания бинарных пакетов из четырех пакетов с включенными надлежащими параметрами и использовать их вместо построения их в портах в каждой системе. Установка бинарного аналогична процессу сборки портов:

      • pkg install sssd-1.11.7_8.txz
        • Ваша версия может отличаться конечно
        • Это установит бинарный пакет для SSSD и извлечет все необходимое из репозитория FreeBSD.
      • pkg add другие пакеты (не устанавливать, не добавлять), сохраняя пакет openldap для последнего.
      • Перед добавлением openldap-sasl-clientсделайтеpkg remove –f openldap-client
        • Это избавляет от не-SASL версии и позволяет устанавливать нашу версию
      • pkg add openldap-sasl-client-2.4.44.txz
        • Опять же, ваша версия может отличаться
      • Вы должны получить необходимые пакеты.
      • Это может быть возможным , чтобы изменить метаданные для двоичного файла SSSD , прежде чем делать то , pkg createчтобы заменить зависимость от openldap-clientс , openldap-sasl-clientчтобы избавиться от необходимости делать это удалить / переустановить. У меня не было времени заняться этим.
        • Кроме того, есть и подчиненные зависимости SSSD openldap-client, поэтому вам также придется их исправить.
      • Обратите внимание, что все эти примечания относятся к версиям этих пакетов, которые в настоящее время находятся в дереве портов на момент написания этой статьи , и к зависимостям, с которыми они связаны. Все это может измениться, когда FreeBSD обновит дерево портов и двоичные файлы. Возможно, однажды у нас будет бинарная версия всего, что вытягивает все нужные зависимости с правильными параметрами, настроенными для функциональности AD прямо из коробки.
    • Конфигурация Kerberos:

      • Пример файла /etc/krb5.conf:
[libdefaults]
   default_realm = MYDOMAIN.NET
   forwardable = true
# Обычно все, что вам нужно в среде AD, так как записи DNS SRV
# идентифицирует серверы / сервисы AD / KRB. Прокомментируйте, если вы
# хотите вручную указать на свой сервер AD
dns_lookup_kdc = true
[] сферы
   MYDOMAIN.NET = {
# Если вы вручную указываете на другой сервер AD, чем в DNS
# admin_server = adserver.mydomain.net
# kdc = adserver.mydomain.net
   }
[Domain_realm]
   mydomain.net = MYDOMAIN.NET
   .mydomain.net = MYDOMAIN.NET
  • (Отступ)
    • Конфигурация SSSD:
      • В этом примере предполагаются атрибуты POSIX в AD для пользователей и групп, обычно необходимые для замены существующей среды, в которой уже установлены UID и GID.
      • Пример файла /usr/local/etc/sssd/sssd.conf:
[SSSD]
config_file_version = 2
домены = MYDOMAIN.NET
services = nss, pam, pac
fallback_homedir = / home /% u

[Домен / MYDOMAIN.NET]
id_provider = ad
access_provider = объявление
auth_provider = ad
chpass_provider = ad
# использовать атрибуты AD POSIX, комментировать, если вы используете автоматически сгенерированный
# UID и GID.
ldap_id_mapping = False
cache_credentials = true
ad_server = adserver.mydomain.net
# если у вас нет bash или чего-либо еще в loginShell учетной записи AD
# атрибут установлен
override_shell = / bin / tcsh
  • (Отступ)
    • Конфигурация PAM:
      • Настройка PAM во FreeBSD немного сложна из-за того, как работает OpenPAM. Я не буду вдаваться в подробности, но чтобы использовать pam_sss для SSSD и заставить его работать, а также чтобы работали логины passwd, вам нужно дважды поместить pam_unix в файл. Из того, что я понимаю, это связано с дополнительной проверкой, которая выполняется "за сценой", которая требует прохождения второго модуля pam_unix.
        • Вот список /etc/pam.dфайлов, которые мне пришлось изменить, чтобы SSSD работал с FreeBSD:

/etc/pam.d/sshd:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / sshd 197769 2009-10-05 09: 28: 54Z des $
#
# Настройка PAM для службы "sshd"
#

# auth
достаточно аутентичный pam_opie.so no_warn no_fake_prompts
требуется авторизация pam_opieaccess.so no_warn allow_local
#auth достаточно pam_krb5.so no_warn try_first_pass
#auth достаточно pam_ssh.so no_warn try_first_pass
достаточно аутентичный pam_unix.so no_warn try_first_pass nullok
достаточно аутентичный pam_sss.so use_first_pass
требуется авторизация pam_unix.so no_warn use_first_pass

# Счет
требуется учетная запись pam_nologin.so
#account required pam_krb5.so
требуется учетная запись pam_login_access.so
требуется учетная запись pam_unix.so
достаточно аккаунта pam_sss.so

# сессия
#session необязательный pam_ssh.so want_agent
сеанс необязательный pam_sss.so
требуется сеанс pam_mkhomedir.so mode = 0700
требуется сеанс pam_permit.so

# пароль
#password достаточный pam_krb5.so no_warn try_first_pass
#password достаточный pam_unix.so try_first_pass use_authtok nullok
достаточно пароля pam_unix.so try_first_pass use_authtok
достаточно пароля pam_sss.so use_authtok

/etc/pam.d/system:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / system 197769 2009-10-05 09: 28: 54Z des $
#
# Общесистемные значения по умолчанию
#

# auth
достаточно аутентичный pam_opie.so no_warn no_fake_prompts
требуется авторизация pam_opieaccess.so no_warn allow_local
#auth достаточно pam_krb5.so no_warn try_first_pass
#auth достаточно pam_ssh.so no_warn try_first_pass
#auth требуется pam_unix.so no_warn try_first_pass nullok
достаточно аутентичный pam_unix.so no_warn try_first_pass
достаточно аутентичный pam_sss.so use_first_pass
требуется авторизация pam_deny.so

# Счет
#account required pam_krb5.so
требуется учетная запись pam_login_access.so
требуется учетная запись pam_unix.so
достаточно аккаунта pam_sss.so

# сессия
#session необязательный pam_ssh.so want_agent
требуется сеанс pam_lastlog.so no_fail
сеанс необязательный pam_sss.so
требуется сеанс pam_mkhomedir.so mode = 0700

# пароль
#password достаточный pam_krb5.so no_warn try_first_pass
#password требуется pam_unix.so no_warn try_first_pass
достаточно пароля pam_unix.so no_warn try_first_pass nullok use_authtok
достаточно пароля pam_sss.so use_authtok
#password требуется pam_deny.so

/etc/pam.d/su:

#
# $ FreeBSD: releng / 11.0 / etc / pam.d / su 219663 2011-03-15 10: 13: 35Z des $
#
# Настройка PAM для службы su
#

# auth
достаточно аутентичный pam_rootok.so no_warn
достаточно аутентичный pam_self.so no_warn
требуется авторизация pam_group.so no_warn group = колесо root_only fail_safe ruser
auth include system.dist

# Счет
Аккаунт включает system.dist

# сессия
требуется сеанс pam_permit.so
  • (Отступ)

    • Ноты:
      • system.distявляется копией стокового /etc/pam.d/systemфайла Он включен в /etc/pam.d/suфайл выше, чтобы избежать проблем с командой su.
      • Можно по-прежнему использовать suучетные записи AD в качестве пользователя root, поскольку после получения имени root suне нужно проходить проверку подлинности, а информация об учетной записи передается через переключатель службы имен через SSSD.
      • Если вы действительно хотите переключиться с одного пользователя (не root) на другого пользователя, его следует использовать sudoтолько из соображений безопасности
      • Вы также можете использовать, ksuи это работает для переключения с пользователя A на пользователя B
        • У Хеймдала ksu/usr/bin) по умолчанию SUID не установлен
          • Чтобы заставить Хеймдаля ksuработать,chmod u+s /usr/bin/ksu
        • MIT Kerberos ( krb5пакет установлен в /usr/local/bin) является SUID при установке
      • Поскольку Heimdal является частью базового пакета, у вас будут оба набора двоичных файлов Kerberos.
        • Вы можете настроить пути по умолчанию так, /usr/local/binкак раньше /usr/bin, и т. Д.
      • ksu запросит у пользователя пароль AD / Kerberos целевого пользователя
      • passwdне удастся изменить пароль AD / Kerberos, даже если вы добавите pam_sss.soPAM-файл passwd. passwdДвоичная поддерживает только локальную и NIS Использование kpasswdизменить пароль на AD / сервер Kerberos (s).
    • Переключатель службы имен:

      • /etc/nsswitch.confФайл должен быть настроен на использование SSS сервиса для паролей и групп. Пример:
        • group: files sss
        • passwd: files sss
    • Присоединение к домену:

      • В * nixs есть два основных инструмента для подключения к Linux
        • adcli
          • Это мой любимый инструмент. Это работает очень хорошо, и все может быть сделано в одной командной строке. Учетные данные могут быть предоставлены не в интерактивном режиме (через стандартный ввод и т. Д.)
          • Не требует делать kinitперед использованием, он делает это для вас на основе предоставленных кредитов.
            • Пример:
              • adcli join -D mydomain.net -U Administrator--show-details –v
              • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
                • Эта форма рекомендуется, поскольку утилита не всегда правильно определяет полное доменное имя. Когда вы предоставляете полное доменное имя, которое соответствует прямому и обратному DNS для хоста, принципы создаются правильно. Если утилита использует неправильное имя хоста (например, не включая домен DNS), некоторые субъекты службы не будут созданы, и такие вещи, как SSH, могут не работать.
        • Самба netутилита
          • netУтилита является частью пакета Samba.
          • Эта утилита требует настройки сведений о домене в smb.confфайле конфигурации, что делает его более сложным и неудобным в использовании, особенно неинтерактивно.
          • Этот инструмент также требует, чтобы вы получили билет Kerberos, прежде чем использовать его с помощью kinit. Опять же, это более неудобно и усложняет неинтерактивное использование в скрипте, так как вместо одного есть два шага.
    • Соображения SSHD:

      • Как заставить SSHD работать с AD и SSSD довольно просто
      • Следующие опции должны быть добавлены в /etc/ssh/sshd_config
        • GSSAPIAuthentication yes
          • Включите аутентификацию GSS API для SSHD. Это заставит SSHD авторизоваться против AD KDC
        • PasswordAuthentication yes
          • Разрешить пользователям входить с паролями. Требуется, если вы хотите, чтобы пользователь получил билет KRB5 при входе в систему. Без этого система не сможет расшифровать TGT, отправленный KDC.
        • ChallengeResponseAuthentication yes
          • Для FreeBSD этот метод работает лучше всего.
            • Убедитесь, что вы настроили PasswordAuthentication noпри использовании этой опции.
            • Это единственный метод, который я нашел для FreeBSD, который работает для изменения пароля с истекшим сроком при входе в систему. Если вы используете другой, он вызывает /bin/passwd, который не поддерживает ничего, кроме NIS и локального файла passwd.
        • GSSAPICleanupCredentials yes
          • (необязательно) Будет ли kdestroyпри выходе
        • GSSAPIStrictAcceptorCheck no
          • (необязательно) Этот параметр часто требуется, если SSHD запутан в отношении своего собственного имени хоста или является многосетевым и т. д., или иным образом использует другой субъект службы для связи с KDC. Обычно SSHD использует субъект-службу host/<FQDN>@REALMдля связи с KDC, но иногда ошибается (например, если имя хоста не соответствует DNS-имени сервера SSH). Эта опция позволяет SSHD использовать любого участника в /etc/krb5.keytabфайле, который включает в себяhost/<FQDN>@REALM
      • В зависимости от комбинации используемых вами опций вам может понадобиться или нет необходимость добавлять принципалы хоста в KDC, чтобы адреса IPv4 и IPv6 вашего хоста ssh -K <ip>работали без запроса пароля (при условии, что вы уже выполнили «kinit», конечно).
jbgeek
источник
Я надеюсь, что это помогает людям. Это в основном скомпилировано из моих собственных заметок при попытке заставить FBSD10 и 11 работать с SSSD и сервером AD. Самой большой проблемой, с которой я столкнулся, были конфиги PAM, которые были поистине шаткими и работали не так, как в linux (ошибки в openpam?), И с упаковкой / зависимостями. Не стесняйтесь комментировать, если у вас есть альтернативные методы. Особенно, если вы работаете со встроенным в Heimdal Kerberos, как это сделал Винициус Феррао в своем Ответе. Я не пробовал, так как SSSD все равно настаивает на получении пакета MIT krb5.
17
Обновлен материал pam.d. Я обнаружил причину вялости openpam и нашел ее решение (дважды использовал модуль pam_unix, чтобы он прошел «скрытый» тест, необходимый для успешного входа в систему).
jbgeek