Najvise bih voleo ako bi moglo nekako sa AWS Directory service da se pokrije sve ovo. Ali mislim da LDAP i Radius nisu moguce.
Sledeca varijanta ako Azure moze.

A na kraju krajeva moze i on prem neki AD, i mozda neka replikacija sa AWS Directory na on premise.
Videh da ima neki fazon sa two-way trust. ali sve sto videh jeste da se on prem menadzuju useri, a na AWS Directory resursi. Pa da on prem useri imaju pristup AWS resursima. Ja bih obrnuto. Da imam na AWS usere sa kojima bih mogao da se auth na te lokalne servere.

bump, da izadjem na homepage, posto retko ko zalazi u ovaj deo foruma :D

Nisam strucnjak za ovo, a i pitanje je sta sve imas od zahteva, ako imas Active Directory on-premise, interna mreza, onda taj deo mozes da resis selidbom na Azure AD.

Ako ti treba za pristupe serverima, verovatno VPN (Cisco ili/i openVPN), lindza ssh..

Ako ti treba SSO za aplikacije, serverless app i api-ije, tj. ako imas nesto od toga, kod njih bi mogao da ides sa drugim resenjima, tipa AWS Cognito ili ako je moguce Azure AD sa SSO funkcijom, ili mozda da hostujes neki svoj Identity server.

Uzmi sa rezervom ovo sto sam napisao, jer u principu jedino sto znam vise od google-a je deo kako osigurati user/app pristup resursima sa nekim Identity Serverom.

Pa mislio sam da sam jasno napisao sta mi treba.

Nemam trenutno nikakvo AD resenje. Znaci krecem od nule.
Ne znam da li Azure AD moze sve ovo da pokrije. Koliko sam shvatio LDAP autentifikacija ne funkcionise preko Azure. I da li bih mogao da namestim Radius server za WiFi autentifikaciju.
Ako bi to radilo, i ako bih mogao da join-ujem linux masine, onda bi mi to bilo super resenje. Azure bi mi bio idp za AWS SSO, a na AWS SSO bih mogao dalje da kreiram "aplikacije" dalje za neke aplikacije ako zatreba.

Nije mi trebalo pa nisam probao, ali imas zvanicnu dokumentaciju, AWS SSO podrzava Azure AD kao identiti provajder, ali kroz SAML :

https://docs.aws.amazon.com/si...st/userguide/azure-ad-idp.html

Mislim da ne moras da uopste expose-ujes LDAP, a kamoli RADIUS. Ovo je zvanican guide, pa ako ti zapne mozes da cimas AWS support (moze i sa developer planom, od 69$/month).


Ako hoces da se logujes na Linux masinu, imas na Microsoft sajtu uputstvo kako se Linux masina joinuje u Azure AD, ima malo vise da se cita i imas custom Microsoft alate. Opet, ne koristis (expose-ujes) nista, samo ide kroz SAML.


Za Aruba, mislim da ti treba Aruba Cloud nalog - onda bi trebalo da moze, opet, da ima plugin za Azure AD, prica Cloud i Cloud, opet nemas RADIUS.


Za 2FA Octa sigurno radi, Duo bi trebalo da radi.


Mislim da gresis sto razmisljas kao da pravis sam servis, tj. da trazis Radius i LDAP iza njega. To jeste normalno resenje, ali ove cloud-cloud price obicno idu malo drugacije :D

Ma to je trivijalno da se namesti na strani AWS SSO. Nije meni to problem :D.

Problem mi je sto ne shvatam kako cu na linux masini da se ulogujem u OS preko SAML-a? Ako moze, meni onda AD ni ne treba, AWS SSO moze da bude idp, tu mogu da kreiram usere i grupe.

Ali SAML je koliko kapiram "web based". Znaci kad se logujem, treba da me redirektuje na stranicu tog "identity provider-a" gde cu da kucam kredencijale, pa posle uspesnog logovanja ce me vratiti na onaj url koji sam stavio kao "return url".




_{[Ovu poruku je menjao CoyoteKG dana 03.08.2021. u 09:42 GMT+1]}

OK, znam da sam imao login sa Azure kredencijalima na ssh, ali je i server bio na Azure. Ima softvera za to. Pogledaj ovako nesto:

https://docs.microsoft.com/en-...owto-vm-sign-in-azure-ad-linux

https://docs.microsoft.com/en-...irectory/fundamentals/auth-ssh

Problem je sto ne znam da li ovo radi na Azure (mada bi trebalo, ne znam sto ne bi), plus sto bi ja to radije resavao kroz nesto drugo. Napravis Ansible ili Puppet koji pravi usere i spusta ssh kljuceve. :) Meni su kljucevi bezbedniji nego password, jedino sto ti nije centralizovan management usera - mada, opet, ne mozes kljuceve tako lako ni u LDAP...

Ja da to radim bi koristio AzureAD za SSO, cisto da bi ga vezao i na stvari tipa mail - mada moguce da to moze i AWS SSO, nisam probao. Za same servere, kljucevi. Slazem se, time razvdajas user management, ali opet, ako ces imati neki server management, onda samo dodajes jednu funckionalnost njemu, a server management ti treba pa treba... Razvdajanje server usera i application usera jeste malo nezgodno, ali, ako vec ides na key-based access (a to nije glupo), onda nije tako strasno. Jedino sto ostaje je sto usera pravis i brises na dva mesta .... E sad, ako automatizujes, pa usera u directory serveru ne pravis isto kroz server management - onda ti server management postaje source of truth, a directory zapravo alat. Malo cudno, ali imas dodatnu prednost da server management config, za razliku od directory-ja, je zapravo kod, pa to mozes da guras u git.

A ja za taj AD sam u fazonu, kao nesto sto svi imaju i sto je must have...
Gde god sam radio uvek je bilo neko domensko okruzenje. Ali on premise.... Ja se nadao da moze full cloud, ali... izgleda ne onako kako bih pretpostavljao da moze. Tako da je mozda vreme da se pozdravim sa razmisljanjem uopste u MS smeru :D.

Verovatno je bolje ici tim nekim alternativnim resenjima... Recimo... Hashicorp Vault sam koristio za neke druge stvari, ali znam da ima neki SSH secret engine koji bi valjda trebalo da odradi dosta toga sto ti kazes :)

https://www.hashicorp.com/products/vault/ssh-with-vault

Pazi, nije lose imati SSO. Samo ja razmisljam kontra :

- Dignes Puppet, ili Ansible Tower (ili samo cepas ansible skripte)
- NJime spustis usere na servere (ako radis od nule, lepo napravis i management, sve jedno ti treba)
- Njima spustis i javne kljuceve (ionako ti trebaju, a ne boli da su u git-u, javni su)
- Njime spustis iste te usere u AD (ima plugin)
- Cepas AD za SSO na servise

Rezultat :

- Git cuva usere
- Git cuva ssh kljuceve
- AD cuva SSO passworde, koje za SSH ionako ne koristis

Kad obruses user iz git-a (tj. iz management-a), sledeci run ga obrise i iz AD-a.

Dodatno, sve izmene su u git-u, imas history. Napravis za svaki i MR, stavis ticket ID i sve ti uredno.

@CoyoteKG : Javi na kraju sta si implementirao, mene zanima... ;)

Hocu :)
Nije losa ni tvoja solucija, samo jos uvek ne vidim kako bih WiFi i OpenVPN resio... OpenVPN bih mogao mozda isto sa ansible da menadzujem usere i da napravim neki zbudz, ali na Arubi videh samo opciju preko LDAP.


Nego, pokusavam sada da napravim neku replikaciju foresta, da imam i u Cloudu i on premise.

I sad u dokumentaciji vidim koje portove treba da otvorim, i izmedju ostalog 636 nad tim DCovima koji su u cloudu.
636 je valjda ldap port.
I uspem sa on prem da se telnetujem na taj port.

Mozda i nije nemoguce dzojnovati on prem masinu. Samo da skontam kako DNS da resim.

tadaaaa, izgleda ipak moze on prem, i radi LDAP. Pojma nemam sad gde sam procitao da to ne moze.

sad jedina briga da imam stabilnu vpn vezu :)

Ja sam kapirao da imas Aruba cloud management, on moze direktno na AzureAD. Ako ti je Azure samo on-prem, onda si u problemu - moras LDAP. Super je ako ti je forest proradio....

Azure ne postoji on prem :D

Ovo sad je AWS Directory Service bez icega on prem. Izgleda za razliku od Azure AD ima LDAP.
Imam VPN izmedju za sada mog lab-a i AWS VPC-a gde su deploy-ovani Domain kontroleri. I iz mog laba mogu da join-ujem masinu na AWS Directory Service. Ne znam gde sam naleteo da nije moguce... ali eto moguce je.

Pojma nemam sta imamo za management, znam da je Aruba, kolega mi share-ovao ekrani videli smo da ima neka sekcija da se podesi sa LDAP parametrima. Znaci to ce sad biti lagano.
Jedino problem ako pukne VPN ka AWS, nece niko moci da se uloguje na WiFi :D. Ali dobro, to moze da se resi razvlacenjem kablova.

Ako je Aruba on prem sam mislio, lapsus tastaturis ;D Imas Aruba cloud management, pa onda on moze da se ukaci na Azure AD direktno. Da, onda ako ti pukne net nema logovanja, mada mislim da taj cloud model ima neko kesiranje (ali nemam blage koliko). Ako je LDAP, onda da - nemas nista.

(Inace, postoji Azure on prem, ali nebitno : https://azure.microsoft.com/en...ck-azure-services-on-premises/ )

Znam da malo kasnim sa odgovorom ali resenje treba da ti izgleda ovako...

1. Lokalno podignes AD
2. Podesis Azure AD
3. Podesis Azure AD Connect i napravis hibrida koji radi u oba smera
4. Linux masine ubacis u domen lokalno
5. Za autentifikaciju koristis AD
6. Za Arube podesavas RADIUS za autentifikaciju domenskih korisnika
7. EC2, kao i bilo sta drugo dodajes u domen najnormalnije
8. VPN konfigurises na mikrotiku, posto pretpostavljam da ti je to glavni router
9. Ako ces imati masine i u cloud-u i on-premise, moras da vpn prema tvom tenantu na AWS-u ili gde vec

U sustini dva dana posla...